Một tiến trình độc hại trên Kubernetes node có thể giả mạo các workload khác và đánh cắp thông tin đăng nhập của chúng, từ đó mở rộng quyền truy cập trên một node chia sẻ. Đây là một điểm yếu bảo mật nghiêm trọng khi kẻ tấn công giành được quyền root trên một node.
Lỗ hổng tiềm ẩn trong việc xác thực danh tính Workload
Vấn đề này ảnh hưởng đến các triển khai SPIFFE và SPIRE, vốn được thiết kế để thay thế các khóa bí mật (secrets) tồn tại lâu dài bằng danh tính (identity) của workload có thời hạn ngắn. Các thông tin xác thực này cho phép các dịch vụ chứng minh danh tính của mình với nhau một cách đáng tin cậy.
Mô hình hoạt động tiêu chuẩn giả định rằng node là đáng tin cậy. Tuy nhiên, giả định này không còn giá trị khi kẻ tấn công kiểm soát được hệ điều hành của node. Các nhà phân tích tại Unit42 đã xác định được cách thức mà kẻ tấn công ở cấp độ root có thể thay đổi dữ liệu cgroup của Linux, vốn được sử dụng trong quá trình kiểm tra workload.
Palo Alto Networks báo cáo rằng kỹ thuật này cho phép một tác nhân SPIRE cục bộ cấp phát danh tính của một workload được đặt cùng vị trí cho một tiến trình do kẻ tấn công kiểm soát. Mặc dù các nhà nghiên cứu cho biết họ chưa quan sát thấy phương pháp này được sử dụng trong thực tế, nhưng tiềm năng khai thác là rất lớn.
Việc một danh tính workload hợp lệ có thể mở ra các đường dẫn được tin cậy mà các thông tin đăng nhập bị đánh cắp thông thường không thể tiếp cận. Kẻ tấn công có thể xác thực với các dịch vụ nội bộ, yêu cầu dữ liệu được bảo vệ hoặc di chuyển giữa các ứng dụng như một dịch vụ hợp pháp.
Các trường hợp tin tặc khai thác các cấu hình sai của Kubernetes cho thấy tại sao bảo mật node và kiểm soát danh tính không thể được xem là các vấn đề riêng biệt. Sự cố này nhấn mạnh tầm quan trọng của việc vá các lỗ hổng CVE kịp thời.
Cách thức hoạt động của SPIFFE và SPIRE
SPIFFE gán cho mỗi workload một tên, một Tài liệu Danh tính Xác minh SPIFFE (SVID) có thời hạn ngắn và một gói tin cậy (trust bundle) để xác thực nó. Các ứng dụng sẽ yêu cầu SVID từ tác nhân SPIRE cục bộ.
Tác nhân sẽ kiểm tra các thuộc tính của tiến trình trước khi trả về thông tin xác thực cho các kết nối mutual TLS hoặc truy cập dựa trên token. Trên Kubernetes, tác nhân có thể kiểm tra đường dẫn cgroup của tiến trình để liên kết nó với một container và pod, sau đó thu thập thông tin chi tiết về namespace và service account.
Tiếp theo, tác nhân so sánh các thông tin này với các quy tắc đăng ký. Khi các giá trị khớp, tác nhân sẽ trả về SVID của workload và các tài liệu cần thiết để sử dụng nó.
Kỹ thuật tấn công giả mạo danh tính
Unit42 đã chứng minh rằng quyền truy cập root có thể thay đổi kết quả của quy trình này. Kẻ tấn công có thể tạo hoặc thao túng một đường dẫn cgroup giống với đường dẫn của một workload mục tiêu và thêm tiến trình của mình vào đó. Tác nhân có thể khớp với các bộ chọn của mục tiêu và cấp phát thông tin xác thực của mục tiêu cho tiến trình độc hại.
Đây là một kỹ thuật hậu khai thác (post-exploitation), không phải là một lỗ hổng từ xa tự động xâm phạm một cụm Kubernetes. Tuy nhiên, phạm vi ảnh hưởng của nó có thể rất nghiêm trọng: mọi danh tính workload trên node bị ảnh hưởng đều phải được coi là đã bị lộ.
Điều này làm cho các báo cáo về lỗ hổng NodeRestriction trên Kubernetes liên quan đến các node bị xâm phạm trở nên quan trọng hơn cả điểm truy nhập ban đầu.
Công cụ Spooffe hỗ trợ phòng vệ
Các nhà nghiên cứu đã tạo ra Spooffe, một công cụ kiểm thử có khả năng quét một node, tái tạo các đường dẫn cgroup cho các workload đang chạy và yêu cầu tác nhân cục bộ cung cấp các danh tính kết quả.
Công cụ này giúp các chuyên gia phòng thủ đánh giá mức độ phơi nhiễm sau khi xảy ra sự cố kiểm soát ở cấp độ quản trị viên. Nó cũng minh họa lý do tại sao các thông tin xác thực có thời hạn ngắn không thể tự giải quyết các thất bại bảo mật ở cấp độ máy chủ.
Các tổ chức nên xem việc truy cập root trên một node tương đương với việc truy cập vào mọi danh tính mật mã được cấp cho nó. Điều này có nghĩa là bảo vệ các worker node với mức độ khẩn cấp tương đương với các hệ thống danh tính, hạn chế chặt chẽ đặc quyền quản trị viên và giám sát các thay đổi bất thường đối với tiến trình, container và cgroups.
Lời khuyên này tương tự với các bài học kinh nghiệm từ việc tin tặc lạm dụng các cấu hình sai của Docker Kubernetes, nơi các container có đặc quyền có thể cung cấp một tuyến đường trực tiếp để kiểm soát máy chủ.
Các nhóm nên chặn các container có đặc quyền khi có thể, hạn chế quyền truy cập trực tiếp vào máy chủ và mạng máy chủ, đồng thời kiểm soát chặt chẽ quyền truy cập vào các giao diện runtime của container.
Các chính sách đăng ký không nên chỉ dựa vào các bộ chọn mà một kẻ tấn công cấp độ root có thể bắt chước. Thiết kế chính sách cụ thể, xem xét thường xuyên và các biện pháp kiểm soát phân lớp có thể ngăn chặn một workload bị xâm phạm trở thành một sự cố ảnh hưởng đến toàn bộ danh tính.
Các chuyên gia phòng thủ nên xác định các workload nhạy cảm chia sẻ node, đặc biệt là các dịch vụ có quyền truy cập rộng vào cơ sở dữ liệu, đám mây hoặc triển khai. Việc tách biệt các workload có giá trị cao và thực thi nguyên tắc đặc quyền tối thiểu (least privilege) có thể giảm thiểu thiệt hại khi một node gặp sự cố.
Hướng dẫn về việc bảo mật các cụm Kubernetes sản xuất cũng nhấn mạnh các biện pháp kiểm soát truy cập mạnh mẽ, phân đoạn và giám sát liên tục. Bài học cốt lõi rất đơn giản: danh tính workload chỉ mạnh bằng máy chủ xác minh nó. SPIFFE và SPIRE giảm thiểu rủi ro từ các bí mật tồn tại lâu dài, nhưng không thể duy trì sự tách biệt sau khi quyền kiểm soát root của máy chủ bị mất.
Các kế hoạch ứng phó sự cố nên bao gồm việc luân chuyển thông tin xác thực, xem xét phiên và điều tra các dịch vụ đã chấp nhận danh tính được cấp phát từ node bị ảnh hưởng. Việc bảo mật an ninh mạng là yếu tố then chốt để ngăn chặn các rủi ro bảo mật này.
