Token đăng ký Rancher lưu plaintext cho phép đăng ký node giả mạo

Rancher cấp các registration token có thời gian tồn tại dài để xác thực node và agent tham gia downstream cluster. Các token này được lưu trữ và làm lộ dưới dạng plaintext, không có thời hạn, vì vậy người dùng độc hại có thể lấy được một token qua Rancher API, etcd, automation đã lưu hoặc truy cập trực tiếp vào file trên node, rồi sử dụng token đó bất kỳ lúc nào để đăng ký một node giả mạo vào cluster.

Package bị ảnh hưởng là github.com/rancher/rancher với trạng thái mặc định là unaffected ngoài các phạm vi được liệt kê:

• Nhánh 2.14: các phiên bản từ 2.14.0 đến trước 2.14.4 bị ảnh hưởng. Bản sửa được advisory xác nhận là 2.14.4.
• Nhánh 2.13: các phiên bản từ 2.13.0 đến trước 2.13.8 bị ảnh hưởng. Bản sửa được advisory xác nhận là 2.13.8.

Bản ghi không xác nhận trạng thái của các nhánh khác ngoài những phạm vi trên; không nên suy ra rằng mọi phiên bản không được liệt kê đều đã được xác minh an toàn.

Rancher cấp registration token để xác thực node và agent khi tham gia downstream cluster. Trong các phiên bản bị ảnh hưởng, token của ClusterRegistrationToken được lưu trong trường plaintext status.Token của CRD và được trả về qua Rancher API. Cùng loại credential này cũng có thể xuất hiện trong các lệnh đăng ký được sao chép vào shell history, CI/CD, infrastructure-as-code, etcd hoặc các bản sao lưu etcd.

Đối với quy trình v2prov cho RKE2/K3s, system agent install script tại /usr/local/custom_script/install.sh được ghi trên node với quyền 0644 và chứa CATTLE_TOKEN, server URL cùng CA checksum. Vì vậy, một local user hoặc process không có quyền root vẫn có thể đọc token nếu có quyền truy cập cục bộ phù hợp.

Kẻ tấn công trước hết phải lấy được một registration token hợp lệ. Các đường tiếp cận được advisory nêu gồm quyền truy cập cấp cluster-admin vào Rancher API, etcd, automation đã lưu token, các lệnh đăng ký đã sao chép, hoặc local code execution không cần root trên node đã provision bằng v2prov. Sau đó, token có thể được dùng để đăng ký node giả mạo với vai trò controlplane hoặc etcd, từ đó có khả năng đạt quyền quản trị đầy đủ đối với downstream cluster bị ảnh hưởng. Chi tiết triển khai không xác nhận rằng mọi deployment đều sử dụng đồng thời cả hai bề mặt lộ token.

Theo bản ghi, đường tấn công được phân loại là local, độ phức tạp thấp, yêu cầu quyền hạn thấp và không cần user interaction. Tuy nhiên, token cũng có thể bị lấy qua các bề mặt quản trị hoặc dữ liệu lưu trữ như Rancher API, etcd, automation, shell history và infrastructure-as-code, nên phạm vi tiếp cận thực tế phụ thuộc vào quyền truy cập sẵn có trong từng môi trường.

Kẻ tấn công phải có được token hợp lệ trước khi đăng ký node; bằng chứng hiện có không mô tả một đường tấn công không cần credential. Do token không hết hạn, token bị lộ có thể tiếp tục được sử dụng cho đến khi bị xoá hoặc thay thế. Bản ghi được cung cấp đánh dấu không có public exploit và không có trạng thái known-exploited, nhưng điều này không chứng minh rằng chưa từng có hành vi lạm dụng.

Kẻ tấn công có token hợp lệ có thể đăng ký một node vào downstream cluster bằng vai trò controlplane hoặc etcd. Theo advisory, điều này có thể đem lại quyền quản trị đầy đủ đối với cluster, bao gồm khả năng truy cập hoặc thay đổi PKI, dữ liệu etcd, secrets và workload.

Tác động có thể bao gồm mất bí mật, thay đổi trái phép dữ liệu hoặc cấu hình, và gián đoạn dịch vụ. Phạm vi tác động vượt ra ngoài nơi lưu token vì credential được dùng để tham gia vào downstream cluster do Rancher quản lý. Điều kiện giới hạn là kẻ tấn công vẫn phải lấy được token hợp lệ; bằng chứng hiện có không cho thấy chỉ cần truy cập mạng vào Rancher là đủ để khai thác.

Nếu một registration token bị lộ, tổ chức có thể mất quyền kiểm soát đối với downstream cluster mà token đó cho phép tham gia. Một node giả mạo có vai trò controlplane hoặc etcd có thể dẫn đến:

• Truy cập hoặc thay đổi dữ liệu etcd, secrets, workload và PKI của cluster.
• Thay đổi cấu hình hoặc workload, làm suy giảm tính toàn vẹn của môi trường Kubernetes.
• Gây gián đoạn dịch vụ hoặc ảnh hưởng đến tính sẵn sàng của cluster.
• Mở rộng phạm vi ảnh hưởng từ nơi token được lưu sang tài nguyên downstream do Rancher quản lý.

Các hậu quả trên là khả năng kỹ thuật của việc đăng ký node với quyền tương ứng, không phải bằng chứng rằng một cluster cụ thể đã bị xâm nhập. Việc đánh giá sự cố cần bao gồm cả các bản sao token trong etcd, automation, CI/CD, infrastructure-as-code và shell history.

1. Nâng cấp theo đúng nhánh đang triển khai: nhánh 2.14 lên 2.14.4, hoặc nhánh 2.13 lên 2.13.8. Đây là biện pháp khắc phục chính đã được xác nhận.
2. Trong thời gian chờ nâng cấp, giảm bề mặt lộ token. Đặt quyền của /usr/local/custom_script/install.sh trên các node provision bằng v2prov thành 0600, đồng thời lưu ý rằng container có host path mount vào /usr/local vẫn có thể đọc file với quyền root.
3. Hạn chế local access trên downstream node, đặc biệt là quyền cho workload không tin cậy truy cập host path. Kiểm soát quyền đọc etcd backup, infrastructure-as-code, cấu hình CI/CD và shell history.
4. Nếu nghi ngờ một system CRT đã bị lộ, xoá CRT đó để buộc tạo token mới, cập nhật credential của cluster agent và redeploy agent. Kết nối mới dùng token cũ sẽ bị từ chối sau khi token được thay thế, nhưng tunnel hiện hữu không tự động bị ngắt; chỉ restart agent không đủ để lấy credential mới.
5. Không có workaround đầy đủ thay thế cho việc nâng cấp. Sau khi xử lý, xác minh lại cả các CRT hiện có và các file bootstrap trên node, vì token cũ có thể đã được sao chép ra ngoài Rancher.

Các bước kiểm tra nên tập trung vào inventory phiên bản, nơi lưu token và các node mới xuất hiện:

1. Xác định phiên bản của package github.com/rancher/rancher và kiểm tra xem hệ thống có nằm trong các nhánh bị ảnh hưởng hay không.
2. Kiểm tra các ClusterRegistrationToken để xác định liệu status.Token còn chứa credential thực tế dạng plaintext hay chỉ chứa placeholder {token}. Trên bản đã vá, giá trị thật được lưu trong Kubernetes Secret và quyền đọc Secret được kiểm soát bằng RBAC.
3. Trên các node downstream được provision bằng v2prov, kiểm tra sự tồn tại, quyền truy cập và nội dung của /usr/local/custom_script/install.sh, đặc biệt là credential CATTLE_TOKEN. Việc file có quyền đọc rộng là dấu hiệu cần xử lý, nhưng không tự nó chứng minh token đã bị lấy cắp.
4. Rà soát quyền truy cập và lịch sử thay đổi đối với etcd, bản sao lưu etcd, kho infrastructure-as-code, cấu hình CI/CD và shell history nơi registration command có thể đã được lưu.
5. Đối chiếu danh sách node, vai trò node và hoạt động quản trị của downstream cluster để phát hiện node controlplane hoặc etcd không mong đợi. Đây là biện pháp giám sát phòng ngừa, không phải một indicator được advisory xác nhận.

Không nên coi việc không tìm thấy log hoặc node bất thường là bằng chứng token chưa từng bị lộ.