Lỗ hổng trong Amazon EKS làm lộ thông tin AWS, cho phép leo thang đặc quyền

[Kaya]

Lỗ hổng từ container cấu hình sai trên Amazon EKS có thể khiến thông tin đăng nhập AWS bị rò rỉ qua HTTP không mã hóa, tạo điều kiện cho kẻ tấn công chiếm quyền điều khiển hệ thống, leo thang đặc quyền và truy cập sâu vào hạ tầng đám mây.

Lỗ hổng bắt nguồn từ dịch vụ Pod Identity Agent trên EKS, vốn được thiết kế để cho phép Pod trong Kubernetes sử dụng IAM Role một cách bảo mật. Tuy nhiên, giao tiếp giữa Pod và dịch vụ này lại sử dụng HTTP không mã hóa tại địa chỉ 169.254.170.23:80, khiến thông tin xác thực có thể bị nghe lén hoặc giả mạo nếu container có quyền truy cập mạng cao.

Các container trong cụm EKS có cấu hình hostNetwork: true hoặc có quyền CAP_NET_ADMIN là đối tượng đặc biệt dễ bị lợi dụng, dẫn đến rò rỉ thông tin đăng nhập AWS IAM Role mà Pod đang sử dụng.

Cách thức tấn công – Phân tích kỹ thuật​

1. Tấn công nghe lén (Packet Sniffing)

• Khi container sử dụng hostNetwork: true, nó chia sẻ cùng một không gian mạng với node.
• Kẻ tấn công có thể dùng công cụ như tcpdump để bắt gói tin truyền qua địa chỉ 169.254.170.23:80 – nơi Pod đang nhận thông tin xác thực từ agent.
• Thông tin này không được ràng buộc theo địa chỉ IP cụ thể nên có thể được dùng lại để truy cập vào các dịch vụ AWS với quyền tương đương.

2. Tấn công giả mạo API (API Spoofing)

• Nếu container có quyền CAP_NET_ADMIN, kẻ tấn công có thể can thiệp vào bảng định tuyến và mạng nội bộ.
• Bằng cách vô hiệu hóa agent HTTP thật và chạy một server giả mạo trên chính địa chỉ IP nội bộ (169.254.170.23:80), hacker sẽ giả dạng dịch vụ cấp IAM Role.
• Token dịch vụ từ Kubernetes sẽ bị đánh cắp và dùng để lấy thông tin đăng nhập AWS thông qua API AssumeRoleForPodIdentity.

Trend Micro đã phát triển mã PoC sử dụng thư viện Python pyroute2 để minh họa quá trình khai thác này.

Ai có thể bị ảnh hưởng?​

• Toàn bộ người dùng EKS đang triển khai container với đặc quyền cao (hostNetwork, CAP_NET_ADMIN).
• Các môi trường CI/CD, production hoặc staging có thể là mục tiêu hàng đầu do thường chứa nhiều container đặc quyền.
• Các tổ chức thiếu kiểm soát cấu hình bảo mật Pod/Container hoặc không có công cụ giám sát runtime hiệu quả.

Mức độ nguy hiểm​

• Tấn công không yêu cầu quyền root hay đặc quyền phức tạp, chỉ cần container có quyền mạng cao.
• Có thể bị khai thác từ bên trong cụm, đặc biệt trong trường hợp kẻ tấn công chiếm được quyền truy cập vào container có đặc quyền.
• Có khả năng mở rộng mức độ tấn công ra toàn bộ tài nguyên AWS, bao gồm S3, EC2, IAM…

Khuyến nghị & biện pháp phòng ngừa​

1. Giảm thiểu quyền container

• Tránh sử dụng hostNetwork: true nếu không thực sự cần thiết.
• Hạn chế quyền Linux bằng securityContext.capabilities.drop để loại bỏ CAP_NET_ADMIN.

2. Áp dụng chính sách bảo mật Pod

• Thiết lập các PodSecurityPolicy để ngăn chặn việc tạo container với quyền đặc biệt.
• Sử dụng các công cụ như OPA/Gatekeeper để kiểm soát cấu hình Pod khi triển khai.

3. Giám sát tại thời điểm chạy

• Kích hoạt giám sát từ Trend Vision One hoặc các giải pháp tương tự để phát hiện hành vi bất thường: container dùng mạng host, container có quyền cao, truyền dữ liệu lạ.
• Kết hợp Amazon GuardDuty để phát hiện container được triển khai trái phép hoặc có hành vi lạ.

4. Quản lý IAM chặt chẽ

• Áp dụng principle of least privilege (PoLP) cho IAM Role gán cho Pod.
• Hạn chế quyền chỉ đủ dùng cho dịch vụ cụ thể, tránh cấp quyền quá rộng.

Lỗ hổng này không đến từ lỗi của AWS mà là do người dùng cấu hình container không an toàn, theo mô hình trách nhiệm chia sẻ. Tuy nhiên, nó cho thấy mức độ rủi ro cực kỳ lớn nếu tổ chức không áp dụng đầy đủ kiểm soát quyền và giám sát hệ thống Kubernetes.

Với tốc độ triển khai cloud-native ngày càng cao, các tổ chức cần đặc biệt đầu tư vào bảo mật runtime, chính sách kiểm soát cấu hình và huấn luyện đội ngũ DevOps/DevSecOps để giảm thiểu tối đa bề mặt tấn công.

Theo WhiteHat.vn​

 

Được phối hợp thực hiện bởi các chuyên gia của Bkav, cộng đồng An ninh mạng Việt Nam WhiteHat và cộng đồng Khoa học công nghệ VnReview