Lỗ hổng rò rỉ thông tin nhạy cảm và leo thang đặc quyền trên Amazon EKS

Amazon Elastic Kubernetes Service (EKS) - một dịch vụ cho phép người dùng triển khai, quản lý và vận hành các cụm Kubernetes lưu trữ trên nền tảng AWS vừa qua đã được giới bảo mật quan tâm do sự xuất hiện của một lỗ hổng nghiêm trọng mới, gây rò rỉ thông tin nhạy cảm và cho phép kẻ tấn công leo thang đặc quyền trên hệ thống.

Thông tin chi tiết

Mới đây, trên diễn đàn của TrendMicro, nhà nghiên cứu bảo mật Jiri Gogela đã đăng tải một bài viết thông báo về sự tồn tại của một lỗ hổng trong Amazon Elastic Kubernetes Service (EKS), cho phép tin tặc có thể lợi dụng để leo thang đặc quyền và tiếp cận thông tin credential trong AWS.

Mục tiêu được nhắm tới bởi lỗ hổng này là Amazon EKS Pod Identity, một tính năng được sử dụng để đơn giản hoá quy trình cấp thông tin xác thực trên AWS cho các pod chạy trong cụm EKS. Dịch vụ hoạt động thông qua extension eks-pod-identity-agent, hoạt động dưới dạng DaemonSet trong kube-system và hiển thị API trên địa chỉ liên kết local 169.254.170.23 cho IPv4 và fd00:ec2::23 cho IPv6 trên cổng 80.

Khi các ứng dụng thực hiện yêu cầu dịch vụ AWS, SDK tự động truy xuất thông tin xác thực tạm thời từ EKS Pod Indentity agent, sau đó tương tác với API AWS để lấy thông tin xác thực cần thiết cho IAM được liên kết. Từ đây, các nhà nghiên cứu bảo mật đã xác định được hai vecto tấn công chính khai thác lỗ hổng này, bao gồm kỹ thuật Packet Sniffing và kỹ thuật API Spoofing.

Đối với kỹ thuật khai thác dựa trên Packet Sniffing, do EKS Pod Identity agent hoạt động trên mỗi nút và hiển thị API trên địa chỉ IP local qua HTTP không được mã hoá, dẫn đến rủi ro bảo mật cao vì bất kỳ pod nào có cấu hình hostNetwork: true đều có khả năng giám sát lưu lượng mạng trên nút, tạo ra hệ quả là pod trên có khả năng chặn bất kỳ thông tin đăng nhập nào được gửi từ điểm cuối API là 169.254.170.23:80. Khi này, một hành động đơn giản như sử dụng công cụ tcpdump cũng có thể chặn bắt thành công bản rõ của thông tin credential được truyền đi.

Hình 1: Đạt được quyền nâng cao thông qua tcpdump - Nguồn: TrendMicro

Với trường hợp khai thác dựa trên kỹ thuật API Spoofing, nếu CAP_NET_RAW bị vô hiệu hoá khỏi container có bật hostNetwork cũng không hoàn toàn loại bỏ được nguy cơ bị khai thác nếu như các quyền cho phép thao thác khác như CAP_NET_ADMIN vẫn được bật. Trong thử nghiệm của mình, các nhà nghiên cứu bảo mật đã phát hiện, chỉ cần một pod độc hại cũng có thể vô hiệu hoá daemon HTTP của eks-pod-identity-agent bằng cách xoá địa chỉ IP liên kết cục bộ mà tiến trình đó đang sử dụng. Điều này tương đương với việc kẻ tấn công có thể chiếm quyền kiểm soát dịch vụ HTTP đang được chạy trên địa chỉ 169.254.170.23:80 và triển khai máy chủ HTTP của riêng mình với khả năng chặn các yêu cầu HTTP đến có chứa mã thông báo uỷ quyền (Authorization token), sau đó sử dụng các thông tin này để lấy thông tin xác thực hợp lệ trên AWS.

Hình 2: Sử dụng thư viện pyroute2 trong python để khai thác lỗ hổng dựa trên kỹ thuật API Spoofing - Nguồn: TrendMicro

Khắc phục & Khuyến nghị

Việc cấu hình không đúng, đặc biệt là khi cấp cho container quá nhiều quyền, đã dẫn tới các rủi ro như trên. Đối với người dùng đang sử dụng Amazon EKS Pod Identity để truy cập tài nguyên AWS trong môi trường Kubernetes cần thực hiện một số hành động sau để giảm thiểu nguy cơ đối mặt với các rủi ro tương tự:

1. Cấp quyền tối thiểu cho container: Chỉ cấp đúng quyền cần thiết, tránh các quyền nguy hiểm như CAP_NET_ADMIN, cấu hình hostNetwork: true, hoặc quyền root không cần thiết.

2. Bảo vệ dịch vụ EKS Pod Identity: Kiểm soát truy cập đến địa chỉ 169.254.170.23 bằng cách sử dụng chính sách mạng (NetworkPolicy) và chỉ cho phép pod đáng tin cậy truy cập.

3. Sử dụng IAM Roles thay cho thông tin xác thực tĩnh: Luôn dùng AWS IAM roles for service accounts (IRSA) để cấp quyền thay vì hard-code AWS credentials trong ứng dụng.

4. Thường xuyên kiểm tra cấu hình và bảo mật: Sử dụng các công cụ như trivy, kube-bench để phát hiện cấu hình rủi ro và kiểm tra định kỳ các tệp triển khai.

Tham khảo

1. An Investigation of AWS Credential Exposure via Overprivileged Containers | Trend Micro (US)