Khai thác Cloud Metadata: AWS IMDSv1/v2 và GCP

TL;DR: Khi các ứng dụng hiện đại được di chuyển lên môi trường đám mây (AWS, Google Cloud, Microsoft Azure), một lỗ hổng SSRF đơn giản có thể nhanh chóng biến thành thảm họa rò rỉ dữ liệu quy mô lớn thông qua Instance Metadata Service (IMDS). Tọa lạc tại địa chỉ IP Link-local quen thuộc 169.254.169.254, dịch vụ này cung cấp toàn bộ thông tin nhận dạng máy ảo, script khởi tạo, và đặc biệt là các thông tin chứng thực IAM tạm thời (Access Keys). Việc thấu hiểu sự khác biệt kiến trúc giữa IMDSv1 và IMDSv2 giúp bạn xây dựng rào cản ngăn chặn kẻ tấn công leo thang đặc quyền.

1. Scenario — Vụ rò rỉ dữ liệu Capital One năm 2019

Tháng 7 năm 2019, ngân hàng Capital One của Mỹ công bố một trong những vụ rò rỉ dữ liệu lớn nhất lịch sử ngành tài chính: thông tin cá nhân và điểm tín dụng của hơn 106 triệu khách hàng bị đánh cắp.

Thủ phạm là Paige Thompson, một cựu kỹ sư AWS. Cuộc tấn công diễn ra theo kịch bản:

1. Phát hiện SSRF trên Web Application Firewall (WAF): Ngân hàng tự cấu hình một reverse proxy WAF mã nguồn mở (ModSecurity) trên một máy ảo EC2 của AWS. Do cấu hình sai, endpoint proxy này dính lỗi SSRF.
2. Khai thác AWS IMDSv1: Kẻ tấn công gửi request qua lỗ hổng SSRF tới địa chỉ:
   HTTP

   Sao chép

   GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
   

   Máy chủ trả về tên IAM Role được gắn cho máy ảo này.
3. Trích xuất Secret Access Key: Kẻ tấn công gửi tiếp request:
   HTTP

   Sao chép

   GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
   

   Máy chủ trả về bộ chứng thực AWS gồm: AccessKeyId, SecretAccessKey, và Token.
4. Đọc trộm toàn bộ S3 Bucket: Nhờ IAM Role được cấp quyền quá rộng rãi (Over-privileged permissions), kẻ tấn công cấu hình bộ chứng thực này vào công cụ AWS CLI cá nhân và thực hiện lệnh aws s3 sync, tải về hơn 700 thư mục và tệp tin chứa dữ liệu nhạy cảm của khách hàng.

Vụ việc này đã thôi thúc toàn bộ ngành công nghệ đám mây phải thiết kế lại cơ chế bảo vệ Instance Metadata Service.

2. Analogy — Quầy phát thẻ bài tự do và quy trình nhận diện hai bước

Hãy tưởng tượng cơ chế cấp thẻ an ninh tại một cơ quan chính phủ:

• Quy trình cũ (IMDSv1 - Quầy mở): Bất kỳ ai đi lại trong sảnh cơ quan chỉ cần bước tới quầy lễ tân và nói: "Cho tôi xin thẻ vào phòng lưu trữ hồ sơ". Cô lễ tân không hỏi giấy tờ, chỉ cần thấy bạn đang đứng bên trong tòa nhà là đưa ngay chiếc thẻ từ không hạn chế. Nếu kẻ gian từ ngoài phố đứng nấp sau lưng một nhân viên để nhờ nói hộ, cô lễ tân vẫn phát thẻ.
• Quy trình mới (IMDSv2 - Xác minh phiên có điều kiện): Cô lễ tân yêu cầu: "Anh phải đưa ngón tay vào máy quét sinh trắc học (phương thức đặc thù PUT kèm header riêng), nhận một tấm vé hẹn có thời hạn 6 tiếng. Sau đó anh mới dùng tấm vé hẹn đó để xin cấp thẻ". Hơn nữa, chiếc máy quét chỉ nhận diện được những người đứng cách quầy dưới nửa mét (giới hạn 1 hop mạng). Kẻ gian từ xa hoàn toàn không thể nhờ người khác bấm hộ.

Trong bảo mật Cloud Metadata, IMDSv2 chính là chiếc máy quét sinh trắc học đó:

3. Vì sao IMDSv2 bảo vệ được hạ tầng đám mây trước SSRF?

Địa chỉ 169.254.169.254 là một địa chỉ IP Link-local (thuộc khối 169.254.0.0/16 theo RFC 3927). Khi một máy ảo EC2 gửi gói tin tới IP này, gói tin không đi ra ngoài Internet hay đi qua router mạng thông thường, mà được hypervisor (Nitro hoặc Xen) chặn bắt và xử lý cục bộ ngay trên card mạng ảo của máy chủ vật lý.

Trong bài học trước, bạn đã tìm hiểu về các kỹ thuật bypass bộ lọc mạng:

3.1. AWS IMDSv1: Không trạng thái và dễ bị khai thác

Trong IMDSv1, việc lấy thông tin credentials chỉ đơn giản là các HTTP GET requests:

# Step 1: Discover attached role name
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Step 2: Extract temporary keys
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/app-production-role

Phản hồi trả về chuỗi JSON chứa đầy đủ thông tin:

{
  "Code": "Success",
  "LastUpdated": "2026-10-27T12:00:00Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token": "AQoDYXdzEJr...",
  "Expiration": "2026-10-27T18:00:00Z"
}

Bất kỳ lỗi SSRF cơ bản nào (kể cả SSRF qua tham số hình ảnh hay PDF generator) đều có thể lấy trọn bộ credentials này.

3.2. AWS IMDSv2: Cơ chế phiên bảo vệ (Session-oriented)

AWS ra mắt IMDSv2 vào tháng 11 năm 2019 nhằm khắc phục triệt để điểm yếu của IMDSv1:

1. Bước 1: Khởi tạo phiên làm việc (Session Token):
   • Client bắt buộc phải gửi một HTTP PUT request.
   • Bắt buộc phải có custom header: X-aws-ec2-metadata-token-ttl-seconds: <giây>.
   Bash

   Sao chép

   TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
     -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
   

2. Bước 2: Sử dụng Session Token để lấy dữ liệu:
   • Sử dụng token vừa nhận được truyền vào header X-aws-ec2-metadata-token:
   Bash

   Sao chép

   curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
     http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role
   

Vì sao IMDSv2 chặn đứng hầu hết các cuộc tấn công SSRF?

• Rào cản HTTP Method: Đa số các lỗ hổng SSRF trong ứng dụng chỉ cho phép thực hiện phương thức HTTP GET (ví dụ tải ảnh, xem trước link). Chúng không hỗ trợ gửi phương thức PUT.
• Rào cản Custom Header: Ngay cả khi ứng dụng hỗ trợ gửi POST/PUT, kẻ tấn công hiếm khi có khả năng tiêm nhiễm thêm các header tùy biến như X-aws-ec2-metadata-token-ttl-seconds vào request.
• Rào cản Network Hop Limit (IP TTL): AWS cho phép cấu hình HttpHopLimit của gói tin IP tới metadata service bằng 1 (mặc định cho EC2). Nếu ứng dụng chạy bên trong một container Docker hoặc nằm sau một reverse proxy, gói tin IP khi đi qua cầu mạng (bridge network) sẽ bị giảm TTL từ 1 về 0, và router nội bộ sẽ tự động hủy gói tin trước khi nó tới được metadata service.

4. Cơ chế bảo vệ trên Google Cloud (GCP) và Azure

Các nhà cung cấp đám mây khác cũng áp dụng các biện pháp phòng vệ tương tự:

Google Cloud Platform (GCP)

GCP cung cấp metadata tại http://metadata.google.internal/computeMetadata/v1/:

• Header bắt buộc: Mọi request tới metadata service của GCP bắt buộc phải có header Metadata-Flavor: Google.
• Nếu thiếu header này, server lập tức trả về mã lỗi HTTP 403 Forbidden.
• Header này ngăn chặn các lỗ hổng SSRF đơn giản không thể chèn header tùy biến.

Microsoft Azure

Azure cung cấp metadata tại http://169.254.169.254/metadata/instance?api-version=2021-02-01:

• Header bắt buộc: Bắt buộc phải có header Metadata: true.
• Nếu thiếu header hoặc thiếu tham số api-version, request sẽ bị từ chối.

# Cloud infrastructure configuration (Terraform)
resource "aws_instance" "web_app" {
ami           = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"

metadata_options {
  http_endpoint = "enabled"
  # Security oversight: allows older vulnerable IMDS version
  http_tokens   = "optional"
}
}

Thử ngẫmNếu một máy ảo EC2 bắt buộc dùng IMDSv2 (http_tokens = required), nhưng ứng dụng lại dính lỗi Command Injection, liệu kẻ tấn công có lấy được credentials không?

Câu trả lời là có: Khi đã có Command Injection (thực thi shell trực tiếp trên máy ảo), kẻ tấn công có thể chạy lệnh curl cục bộ với phương thức PUT để lấy token IMDSv2 bình thường. IMDSv2 sinh ra để chống SSRF từ bên ngoài, chứ không thể chống được RCE cục bộ.

5. Pitfalls & Giải pháp khắc phục triệt để

❌ Bẫy thường gặp: Cho phép IAM Role có quyền AdministratorAccess

Sai lầm nghiêm trọng của nhiều đội ngũ DevOps là gán các IAM Role có quyền quá rộng (như AdministratorAccess hoặc * trên mọi bucket S3) cho các máy ảo chạy ứng dụng web công cộng. Khi ứng dụng bị SSRF, kẻ tấn công chiếm được quyền hạn tương đương với người quản trị cao nhất của toàn bộ tài khoản cloud.

✅ Giải pháp chuẩn mực: Bắt buộc IMDSv2 và Áp dụng Least Privilege

Quy chuẩn bảo mật hạ tầng đám mây:

1. Bắt buộc kích hoạt IMDSv2 (Enforce IMDSv2):
   • Trên AWS CLI:
     Bash

     Sao chép

     aws ec2 modify-instance-metadata-options \
       --instance-id i-1234567890abcdef0 \
       --http-tokens required \
       --http-endpoint enabled
     

   • Trong Terraform: Cấu hình http_tokens = "required".
2. Thiết lập Service Control Policy (SCP):
   • Viết policy cấp AWS Organization cấm bất kỳ tài khoản nào tạo EC2 mà không bật IMDSv2.
3. Nguyên tắc quyền tối thiểu (Least Privilege):
   • Chỉ cấp cho IAM Role quyền truy cập vào đúng các tài nguyên tối thiểu cần thiết (ví dụ chỉ đọc đúng 1 thư mục trong S3 bucket cụ thể).
4. Chặn địa chỉ 169.254.169.254 ở tầng container:
   • Nếu chạy ứng dụng trên Docker hoặc Kubernetes, sử dụng lệnh iptables để chặn container gửi gói tin tới dải link-local:
     Bash

     Sao chép

     iptables -A OUTPUT -d 169.254.169.254/32 -j DROP
     

6. Đào sâu

Tài liệu tham khảo chuyên sâu về Cloud Metadata Security:

• AWS Security Blog — Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with IMDSv2: Bài viết công bố nguyên lý thiết kế và cơ chế bảo vệ của IMDSv2.
• Google Cloud Documentation — Storing and retrieving instance metadata: Đặc tả kỹ thuật về metadata service và header Metadata-Flavor: Google.
• Azure Documentation — Azure Instance Metadata Service (Windows and Linux): Hướng dẫn bảo vệ metadata endpoint trên Microsoft Azure.

7. Tóm tắt

• Dịch vụ Instance Metadata Service (IMDS) tại địa chỉ 169.254.169.254 là mục tiêu giá trị cao nhất trong các cuộc tấn công SSRF trên môi trường cloud.
• AWS IMDSv1 chỉ yêu cầu HTTP GET đơn giản, từng là nguyên nhân trực tiếp của vụ rò rỉ dữ liệu lịch sử Capital One.
• AWS IMDSv2 bảo vệ toàn diện bằng cơ chế phiên hai bước (yêu cầu HTTP PUT kèm token TTL) và kiểm soát số hop mạng IP.
• GCP và Azure yêu cầu các custom headers đặc thù để ngăn chặn các request SSRF không tùy biến được header.
• Phòng thủ đa tầng bằng cách bắt buộc kích hoạt IMDSv2 (http_tokens = required), áp dụng Least Privilege cho IAM Role và chặn dải link-local ở firewall container.

8. Tự kiểm tra

Bài tiếp theo: Lỗ hổng REST API: Khai thác BOLA và Mass Assignment