Nguy Cơ Lộ Thông Tin Xác Thực AWS trong EKS: Lỗi Cấu Hình Container

Phân Tích Chuyên Sâu: Rủi Ro Lộ Thông Tin Xác Thực AWS trong Amazon EKS do Cấu Hình Container

Các nghiên cứu gần đây đã làm sáng tỏ những vấn đề bảo mật nghiêm trọng trong Amazon Elastic Kubernetes Service (EKS). Các vấn đề này liên quan đến việc các container được cấp đặc quyền quá mức hoặc cấu hình sai, dẫn đến việc lộ các thông tin xác thực AWS nhạy cảm. Những lỗ hổng này chủ yếu phát sinh từ cách Amazon EKS Pod Identity quản lý quyền truy cập thông tin xác thực AWS bên trong các pod Kubernetes, đặc biệt khi các container sở hữu đặc quyền hoặc khả năng mạng vượt quá mức cần thiết.

Chi Tiết Lỗ Hổng

Điểm Yếu Cốt Lõi

Amazon EKS Pod Identity cung cấp một điểm cuối API để lấy thông tin xác thực tại địa chỉ http://169.254.170.23:80. Điều đáng chú ý là giao tiếp tại điểm cuối này hoàn toàn không được mã hóa (HTTP). Điều này tạo ra một điểm yếu nghiêm trọng khi các container có khả năng truy cập mạng máy chủ (được cấu hình hostNetwork: true) có thể dễ dàng đánh hơi lưu lượng truy cập HTTP này và thu thập các thông tin xác thực AWS được truyền đi dưới dạng văn bản rõ.

Một yếu tố rủi ro bổ sung là các thông tin xác thực được tiết lộ không bị ràng buộc với một máy chủ cụ thể. Điều này có nghĩa là khi một kẻ tấn công thu được các thông tin xác thực này, chúng có thể sử dụng chúng để giả mạo quyền truy cập và leo thang đặc quyền trong toàn bộ môi trường, vượt ra ngoài phạm vi của pod hoặc máy chủ ban đầu.

Các Kịch Bản Tấn Công

1. Đánh Cắp Gói Tin (Packet Sniffing)

Kịch bản tấn công đầu tiên liên quan đến việc đánh cắp gói tin. Các pod độc hại hoặc bị chiếm quyền kiểm soát, được cấu hình với quyền truy cập mạng máy chủ (hostNetwork: true), có khả năng sử dụng các công cụ phổ biến như tcpdump để giám sát lưu lượng mạng cục bộ. Do thông tin xác thực AWS được gửi qua giao thức HTTP không mã hóa, việc đánh chặn các thông tin này trở nên dễ dàng và hiển nhiên. Kẻ tấn công có thể thu thập các thông tin xác thực tạm thời của vai trò IAM (IAM role temporary credentials) được các pod sử dụng để truy cập các dịch vụ AWS như Amazon S3 hoặc Amazon DynamoDB.

2. Giả Mạo API / Chiếm Đoạt Dịch Vụ Cấp Phát Credential (API Spoofing / Credential Service Hijacking)

Kịch bản tấn công thứ hai thậm chí còn tinh vi hơn. Ngay cả khi container không có khả năng chụp gói tin thô (thiếu quyền CAP_NET_RAW), kẻ tấn công vẫn có thể thực hiện một cuộc tấn công nguy hiểm nếu chúng có quyền quản trị mạng (CAP_NET_ADMIN). Với quyền này, kẻ tấn công có thể thao túng các giao diện mạng của container.

Cụ thể, bằng cách sử dụng thư viện Python pyroute2, kẻ tấn công có thể vô hiệu hóa dịch vụ cấp phát thông tin xác thực EKS hợp pháp. Sau đó, chúng có thể triển khai một phiên bản dịch vụ giả mạo độc hại, được thiết kế để trả về các thông tin xác thực giả mạo hoặc do kẻ tấn công kiểm soát. Điều này cho phép kẻ tấn công chiếm quyền kiểm soát các phiên làm việc và thực hiện các hành động trái phép trong môi trường AWS.

Yêu Cầu Đặc Quyền để Khai Thác

Để thực hiện thành công các kịch bản khai thác này, kẻ tấn công cần có quyền truy cập vào các khả năng cụ thể của container, bao gồm:

• Cấu hình mạng máy chủ: hostNetwork: true
• Các khả năng Linux nâng cao như: CAP_NET_RAW (cho phép chụp gói tin thô) hoặc ít nhất CAP_NET_ADMIN (cho phép thao tác các giao diện mạng).

Việc cấp các đặc quyền này cho các pod và container thường không cần thiết và cần được xem xét cẩn thận để tránh tạo ra các bề mặt tấn công không mong muốn.

Phân Tích Kỹ Thuật

Điểm yếu cốt lõi bắt nguồn từ cấu hình sai của các thiết lập bảo mật pod Kubernetes, cho phép cấp các đặc quyền quá mức. Điểm cuối API bị lộ sử dụng giao thức HTTP không mã hóa trên địa chỉ IP link-local 169.254.170.23 cổng 80. Địa chỉ IP này thường được sử dụng cho các dịch vụ nội bộ và không được định tuyến ra ngoài, nhưng lại dễ dàng truy cập từ bên trong một mạng nội bộ của nút (node) hoặc cluster.

Kẻ tấn công khai thác điểm yếu này bằng cách đánh chặn các thông tin xác thực tạm thời của vai trò IAM dưới dạng văn bản rõ. Các thông tin này được các pod sử dụng để xác thực và truy cập các dịch vụ AWS khác nhau (ví dụ: truy xuất dữ liệu từ Amazon S3, quản lý bảng DynamoDB, v.v.). Việc chiếm đoạt các thông tin xác thực này có thể dẫn đến việc kiểm soát tài nguyên AWS của khách hàng, gây ra rủi ro nghiêm trọng về bảo mật dữ liệu và hoạt động.

Phản Hồi và Công Bố từ Nhà Cung Cấp

Những vấn đề này đã được báo cáo thông qua Zero Day Initiative™ của Trend Micro, được định danh là ZDI-CAN-26891. Phản hồi của AWS về vấn đề này là một điểm quan trọng cần được hiểu rõ.

AWS đã nêu rõ:

“Hành vi được mô tả không được coi là một vấn đề bảo mật mà là hành vi mong đợi trong ranh giới tin cậy của chính nút và thuộc trách nhiệm của khách hàng theo Mô Hình Trách Nhiệm Chia Sẻ (Shared Responsibility Model).”

AWS tiếp tục nhấn mạnh:

“Việc các nhà điều hành nút/cluster đảm bảo các ứng dụng với quyền hạn cao được giới hạn phù hợp là trách nhiệm của họ.”

Quan điểm này của AWS nhất quán với các thực tiễn tốt nhất hiện có về bảo mật pod EKS, trong đó khuyến nghị cấu hình theo nguyên tắc đặc quyền tối thiểu (principle of least privilege). Điều này có nghĩa là mặc dù cơ chế cấp phát thông tin xác thực có tồn tại, việc khách hàng cấp quá nhiều quyền cho các container của họ, đặc biệt là quyền truy cập mạng máy chủ, là nguyên nhân gốc rễ của rủi ro này. Theo Mô Hình Trách Nhiệm Chia Sẻ, AWS chịu trách nhiệm về “bảo mật của đám mây” (bao gồm cơ sở hạ tầng EKS), trong khi khách hàng chịu trách nhiệm về “bảo mật trong đám mây” (bao gồm cấu hình ứng dụng, pod và các quyền liên quan).

Khuyến Nghị và Biện Pháp Giảm Thiểu

Để giảm thiểu rủi ro này, các tổ chức cần thực hiện các biện pháp sau:

• Kiểm tra và cấu hình lại đặc quyền của container:
  • Tránh sử dụng không cần thiết cấu hình mạng máy chủ (hostNetwork: true). Cấu hình này cho phép pod chia sẻ không gian tên mạng của nút chủ, có nghĩa là pod có thể nhìn thấy tất cả lưu lượng mạng trên nút đó, bao gồm cả lưu lượng nhạy cảm.
  • Tránh cấp các Linux capabilities nâng cao như CAP_NET_RAW (cho phép đọc gói tin thô) hoặc CAP_NET_ADMIN (cho phép quản lý cấu hình mạng). Các khả năng này cung cấp cho container quyền kiểm soát mạng ở cấp độ rất thấp, mở ra cánh cửa cho các cuộc tấn công đánh cắp hoặc giả mạo. Chỉ cấp các khả năng này khi thực sự cần thiết cho chức năng của ứng dụng và không có giải pháp thay thế an toàn hơn.
• Thực thi nguyên tắc đặc quyền tối thiểu (Principle of Least Privilege) trên các vai trò IAM liên kết với các pod:
  • Mỗi pod chỉ nên được cấp các quyền IAM tối thiểu cần thiết để thực hiện chức năng của nó. Ví dụ, nếu một pod chỉ cần đọc từ một bucket S3 cụ thể, vai trò IAM của nó chỉ nên có quyền s3:GetObject trên bucket đó, thay vì s3:* hoặc quyền truy cập vào tất cả các bucket. Điều này giúp hạn chế phạm vi thiệt hại nếu thông tin xác thực bị lộ.
• Giám sát hoạt động mạng đáng ngờ bên trong các cluster:
  • Triển khai các công cụ giám sát và ghi log mạng mạnh mẽ. Tìm kiếm các dấu hiệu của các hoạt động như đánh hơi gói tin (ví dụ: việc triển khai tcpdump trong một pod không được phép), các nỗ lực giả mạo API, hoặc các cuộc gọi API AWS bất thường từ các pod không mong muốn. Các hệ thống SIEM (Security Information and Event Management) hoặc các giải pháp giám sát an ninh đám mây có thể giúp phát hiện các hành vi bất thường này.

Chi Tiết Hạ Tầng và Lệnh Liên Quan

Việc hiểu rõ các công cụ và lệnh có thể được sử dụng trong kịch bản tấn công là rất quan trọng để xây dựng cơ chế phòng thủ hiệu quả.

Ví dụ về việc sử dụng công cụ đánh cắp gói tin bên trong một pod có đặc quyền:

# Packet sniffing example using tcpdump inside a privileged pod:
tcpdump -i any port 80

Lệnh tcpdump -i any port 80 sẽ lắng nghe tất cả các gói tin trên cổng 80 trên bất kỳ giao diện mạng nào mà pod có quyền truy cập, bao gồm cả lưu lượng giao tiếp với điểm cuối EKS Pod Identity.

Một công cụ khác được đề cập trong các bằng chứng khái niệm (Proof-of-Concept – PoC) khai thác là thư viện Python pyroute2. Thư viện này được sử dụng để thao tác các giao diện mạng Linux, cho phép kẻ tấn công vô hiệu hóa hoặc chuyển hướng lưu lượng mạng đến các dịch vụ giả mạo.

Công Nghệ Liên Quan Được Đề Cập

Dưới đây là các công nghệ và thành phần quan trọng được nhắc đến trong phân tích này:

• Amazon EKS Pod Identity: Một tính năng của Amazon EKS cho phép các pod Kubernetes dễ dàng giả định các vai trò IAM, từ đó cấp cho chúng quyền truy cập vào các tài nguyên AWS một cách an toàn mà không cần quản lý khóa truy cập tĩnh.
• eks-pod-identity-agent: Một tác nhân chạy trên mỗi nút EKS, chịu trách nhiệm cung cấp API để các pod lấy thông tin xác thực tạm thời từ IAM. Điểm yếu nằm ở chỗ API này sử dụng HTTP không mã hóa.
• pyroute2: Một thư viện Python dùng để tương tác với các cấu hình mạng Linux thông qua giao thức Netlink. Trong các PoC khai thác, nó được sử dụng để thao túng giao diện mạng, cho phép kẻ tấn công chuyển hướng lưu lượng và chiếm đoạt dịch vụ.
• CAP_NET_RAW: Một khả năng (capability) của Linux cho phép một tiến trình tạo và thao tác các gói tin thô, bao gồm khả năng đánh cắp gói tin trên mạng.
• CAP_NET_ADMIN: Một khả năng (capability) của Linux cho phép một tiến trình thực hiện các tác vụ quản trị mạng, như cấu hình giao diện mạng, định tuyến, tường lửa, và các thiết lập mạng khác. Quyền này cho phép kẻ tấn công kiểm soát đáng kể hành vi mạng của container.

Chỉ Số Thỏa Hiệp (Indicators of Compromise – IOCs)

Trong bối cảnh của lỗ hổng này, các chỉ số thỏa hiệp chính giúp nhận diện hoạt động đáng ngờ tập trung vào điểm cuối và phương pháp tấn công:

• Điểm cuối API không mã hóa: http://169.254.170.23:80. Mọi lưu lượng truy cập HTTP không mã hóa đến hoặc từ điểm cuối này từ các pod không được phép đều cần được điều tra.

Không Có CVE hoặc Kỹ Thuật MITRE ATT&CK Được Đề Cập Rõ Ràng

Bài viết này không chỉ định bất kỳ định danh CVE (Common Vulnerabilities and Exposures) nào chính thức, cũng như không ánh xạ rõ ràng các hành vi này vào các kỹ thuật MITRE ATT&CK cụ thể. Tuy nhiên, các kỹ thuật ATT&CK có liên quan có thể được suy ra bao gồm:

• T1040 Network Sniffing: Kỹ thuật này liên quan đến việc giám sát lưu lượng mạng để thu thập thông tin nhạy cảm như thông tin xác thực. Kịch bản đánh cắp gói tin được mô tả hoàn toàn khớp với kỹ thuật này.

Điều quan trọng cần lưu ý là không có các họ mã độc (malware families), nhóm APT/tội phạm, chiến thuật tấn công SEO poisoning, hoặc các ví dụ dòng lệnh cụ thể nào khác ngoài việc sử dụng tcpdump được nêu chi tiết. Tương tự, không có hàm băm tệp (file hashes) hoặc URL liên quan trực tiếp đến các công cụ khai thác nào được cung cấp, ngoài các địa chỉ IP nội bộ của cluster và các điểm cuối liên quan đến kịch bản khai thác (169.254.170.23:80).