Các nhà nghiên cứu an ninh mạng vừa trình diễn một chuỗi leo thang đặc quyền “đầu cuối” (end-to-end privilege escalation chain) trong Amazon Elastic Container Service (ECS). Lỗ hổng này có thể bị kẻ tấn công khai thác để di chuyển ngang (lateral movement), truy cập dữ liệu nhạy cảm và giành quyền kiểm soát môi trường đám mây.

Kỹ thuật tấn công này được Naor Haziz, một nhà nghiên cứu tại Sweet Security, đặt tên là ECScape. Ông đã trình bày phát hiện của mình tại hội nghị an ninh Black Hat USA ở Las Vegas.

Haziz cho biết họ đã tìm ra cách lạm dụng một giao thức nội bộ ECS không được ghi lại để chiếm đoạt thông tin đăng nhập AWS thuộc về các tác vụ ECS khác trên cùng một phiên bản EC2. Một container độc hại với vai trò IAM (Identity and Access Management) có đặc quyền thấp có thể lấy được quyền của một container có đặc quyền cao hơn đang chạy trên cùng một máy chủ.

Amazon ECS là một dịch vụ điều phối container được quản lý hoàn toàn, cho phép người dùng triển khai, quản lý và mở rộng các ứng dụng container hóa, đồng thời tích hợp với Amazon Web Services (AWS) để chạy khối lượng công việc container trong đám mây.

Lỗ hổng được Sweet Security xác định về cơ bản cho phép leo thang đặc quyền bằng cách cho phép một tác vụ có đặc quyền thấp chạy trên một phiên bản ECS chiếm đoạt các đặc quyền IAM của một container có đặc quyền cao hơn trên cùng một máy EC2 bằng cách đánh cắp thông tin đăng nhập của nó.

Nói cách khác, một ứng dụng độc hại trong một cụm ECS có thể đảm nhận vai trò của một tác vụ có nhiều đặc quyền hơn. Điều này được tạo điều kiện thuận lợi bằng cách tận dụng một dịch vụ metadata (metadata service) chạy tại địa chỉ 169.254.170[.]2, nơi cung cấp thông tin đăng nhập tạm thời liên kết với vai trò IAM của tác vụ.

Mặc dù phương pháp này đảm bảo rằng mỗi tác vụ đều nhận được thông tin đăng nhập cho vai trò IAM của nó và chúng được cung cấp tại thời điểm chạy, nhưng việc rò rỉ danh tính của ECS agent có thể cho phép kẻ tấn công mạo danh agent và lấy thông tin đăng nhập cho bất kỳ tác vụ nào trên máy chủ. Toàn bộ quy trình diễn ra như sau:

1. Lấy thông tin đăng nhập vai trò IAM của máy chủ (EC2 Instance Role) để mạo danh agent.
2. Khám phá điểm cuối của ECS control plane mà agent giao tiếp.
3. Thu thập các định danh cần thiết (tên cụm/ARN, ARN phiên bản container, thông tin phiên bản Agent, phiên bản Docker, phiên bản giao thức ACS và số Sequence) để xác thực với tư cách là agent bằng điểm cuối Task Metadata và ECS introspection API.
4. Giả mạo và ký Yêu cầu WebSocket của Agent Communication Service (ACS) mạo danh agent với tham số sendCredentials được đặt thành “true”.
5. Thu thập thông tin đăng nhập cho tất cả các tác vụ đang chạy trên phiên bản đó.

Haziz cho biết: “Kênh agent giả mạo cũng vẫn hoạt động bí mật. Phiên độc hại của chúng tôi bắt chước hành vi dự kiến của agent – thừa nhận tin nhắn, tăng số sequence, gửi heartbeat – vì vậy không có gì sai sót.”

“Bằng cách mạo danh kết nối upstream của agent, ECScape hoàn toàn phá vỡ mô hình tin cậy đó: một container bị xâm phạm có thể thu thập thụ động thông tin đăng nhập vai trò IAM của mọi tác vụ khác trên cùng một phiên bản EC2 và ngay lập tức hành động với các đặc quyền đó.”

ECScape có thể gây ra hậu quả nghiêm trọng khi chạy các tác vụ ECS trên các máy chủ EC2 dùng chung, vì nó mở ra cánh cửa cho việc leo thang đặc quyền giữa các tác vụ, lộ bí mật và khai thác metadata.

Sau khi tiết lộ một cách có trách nhiệm, Amazon đã nhấn mạnh sự cần thiết của khách hàng trong việc áp dụng các mô hình cô lập mạnh mẽ hơn khi có thể và làm rõ trong tài liệu của mình rằng không có sự cô lập tác vụ nào trong EC2 và “container có khả năng truy cập thông tin đăng nhập cho các tác vụ khác trên cùng một phiên bản container.”

Các biện pháp giảm thiểu được khuyến nghị bao gồm tránh triển khai các tác vụ có đặc quyền cao cùng với các tác vụ không tin cậy hoặc có đặc quyền thấp trên cùng một phiên bản, sử dụng AWS Fargate để cô lập thực sự, tắt hoặc hạn chế quyền truy cập dịch vụ metadata phiên bản (IMDS) cho các tác vụ, giới hạn quyền của ECS agent và thiết lập cảnh báo CloudTrail để phát hiện việc sử dụng bất thường các vai trò IAM.

Haziz cho biết: “Bài học cốt lõi là bạn nên coi mỗi container là có khả năng bị xâm phạm và hạn chế nghiêm ngặt bán kính ảnh hưởng của nó. Các trừu tượng thuận tiện của AWS (vai trò tác vụ, dịch vụ metadata, v.v.) giúp cuộc sống của các nhà phát triển dễ dàng hơn, nhưng khi nhiều tác vụ có các cấp đặc quyền khác nhau dùng chung một máy chủ cơ bản, thì bảo mật của chúng chỉ mạnh bằng các cơ chế cô lập chúng – các cơ chế có thể có những điểm yếu tinh vi.”

Sự phát triển này diễn ra sau một số điểm yếu bảo mật liên quan đến đám mây đã được báo cáo trong những tuần gần đây:

• Một race condition trong tích hợp GitHub của Google Cloud Build có thể cho phép kẻ tấn công bỏ qua đánh giá của người duy trì và xây dựng mã chưa được xem xét sau khi người duy trì đưa ra lệnh “/gcbrun”.
• Một lỗ hổng thực thi mã từ xa trong Oracle Cloud Infrastructure (OCI) Code Editor mà kẻ tấn công có thể sử dụng để chiếm đoạt môi trường Cloud Shell của nạn nhân và có khả năng xoay trục qua các dịch vụ OCI bằng cách đánh lừa nạn nhân, người đã đăng nhập vào Oracle Cloud, truy cập một trang HTML độc hại được lưu trữ trên máy chủ thông qua một cuộc tấn công drive-by.
• Một kỹ thuật tấn công có tên I SPy khai thác Service principal (SP) của ứng dụng bên thứ nhất của Microsoft trong Entra ID để duy trì và leo thang đặc quyền thông qua xác thực liên kết.
• Một lỗ hổng leo thang đặc quyền trong dịch vụ Azure Machine Learning cho phép kẻ tấn công chỉ có quyền truy cập Storage Account sửa đổi các tập lệnh invoker được lưu trữ trong tài khoản lưu trữ AML và thực thi mã tùy ý trong một pipeline AML, cho phép chúng trích xuất bí mật từ Azure Key Vaults, leo thang đặc quyền và giành quyền truy cập rộng hơn vào tài nguyên đám mây.
• Một scope vulnerability trong chính sách được quản lý bởi AWS AmazonGuardDutyFullAccess cũ có thể cho phép tiếp quản toàn bộ tổ chức từ một tài khoản thành viên bị xâm phạm bằng cách đăng ký một quản trị viên được ủy quyền tùy ý.
• Một kỹ thuật tấn công lạm dụng Azure Arc để leo thang đặc quyền bằng cách tận dụng vai trò Azure Connected Machine Resource Administrator và như một persistence mechanism bằng cách thiết lập làm command-and-control (C2).
• Một trường hợp các vai trò Reader tích hợp của Azure được cấp quá nhiều đặc quyền và một lỗ hổng trong Azure API có thể bị kẻ tấn công xâu chuỗi để làm rò rỉ khóa VPN và sau đó sử dụng khóa này để truy cập cả tài sản đám mây nội bộ và mạng tại chỗ.
• Một supply chain compromise vulnerability trong Google Gerrit có tên GerriScary cho phép gửi mã trái phép đến ít nhất 18 dự án của Google, bao gồm ChromiumOS (CVE-2025-1568, CVSS score: 8.8), Chromium, Dart và Bazel, bằng cách khai thác các cấu hình sai trong quyền “addPatchSet” mặc định, xử lý nhãn của hệ thống bỏ phiếu và một race condition với thời gian gửi mã bot trong quá trình hợp nhất mã.
• Một misconfiguration Google Cloud Platform exposed các subnetworks được sử dụng cho các member exchange tại Internet Exchange Points (IXPs), do đó cho phép kẻ tấn công có khả năng lạm dụng cơ sở hạ tầng đám mây của Google để giành quyền truy cập trái phép vào LAN IXP nội bộ.
• Một phần mở rộng của privilege escalation vulnerability Google Cloud có tên ConfusedFunction có thể được điều chỉnh cho các nền tảng đám mây khác như AWS và Azure bằng cách sử dụng AWS Lambda và Azure Functions, tương ứng, ngoài việc mở rộng nó để thực hiện environment enumeration.

Talos cho biết: “Chiến lược giảm thiểu hiệu quả nhất để bảo vệ môi trường của bạn khỏi hành vi của các tác nhân đe dọa tương tự là đảm bảo rằng tất cả SA [Service Account] trong môi trường đám mây của bạn tuân thủ nguyên tắc đặc quyền tối thiểu và không có SA đám mây cũ nào vẫn được sử dụng. Đảm bảo rằng tất cả các dịch vụ và phụ thuộc trên đám mây đều được cập nhật các bản vá bảo mật mới nhất. Nếu có SA cũ, hãy thay thế chúng bằng SA có đặc quyền tối thiểu.”

Giải thích thuật ngữ:

• Leo thang đặc quyền (Privilege escalation): Là hành động khai thác các lỗi hoặc sơ hở trong hệ thống để có được quyền truy cập cao hơn mức được cho phép ban đầu.
• IAM (Identity and Access Management): Quản lý danh tính và quyền truy cập, kiểm soát ai có quyền làm gì trong hệ thống.
• Metadata: Dữ liệu mô tả dữ liệu khác, ví dụ như thông tin về tác giả, thời gian tạo của một tập tin.
• Race condition: Lỗi xảy ra khi nhiều tiến trình cùng truy cập và thay đổi một tài nguyên, dẫn đến kết quả không mong muốn.
• Service Principal (SP): Một danh tính bảo mật được gán cho một ứng dụng hoặc dịch vụ để truy cập tài nguyên.