Cách tìm AWS account ID của một S3 bucket bất kỳ

Tìm AWS account ID của S3 bucket

• Năm 2021, Ben Bridts đã công bố một phương pháp độc đáo để tìm AWS account ID của các S3 bucket công khai.
• Bài viết này giải thích kỹ thuật tìm account ID cho cả S3 bucket riêng tư lẫn công khai.

Từ S3 bucket đến AWS account ID

• Trình bày kỹ thuật tìm AWS account ID trước đó chưa được biết đến của bucket có tên bucket-alpha thông qua đầu ra shell.

Chính xác thì kỹ thuật này hoạt động như thế nào?

• Phân tích lý do kỹ thuật của Ben hoạt động và kết hợp ba yếu tố cốt lõi:
  • Khả năng áp dụng IAM policy vào request
  • Khả năng suy ra liệu IAM policy có cho phép request hay không
  • Khả năng áp dụng wildcard match cho khóa điều kiện s3:ResourceAccount

Giải pháp

• Tìm ra một giải pháp sử dụng VPC endpoint cho S3 và tận dụng sự khác biệt trong hành vi khi request bị từ chối trong CloudTrail.

Xem từng bước

• Quy trình từng bước khi muốn tìm account ID của bucket bucket-alpha:
  • Xác định vùng của bucket
  • Triển khai VPC và VPC endpoint trong cùng vùng
  • Khởi chạy EC2 instance trong VPC và xác nhận đang dùng VPC endpoint cho S3
  • Chỉnh sửa VPC endpoint policy để xác định liệu account ID của bucket mục tiêu có bắt đầu bằng "0" hay không
  • Gửi request tới bucket mục tiêu
  • Kiểm tra xem request có xuất hiện trong CloudTrail hay không
  • Dựa trên kết quả, chỉnh sửa VPC endpoint policy để tiếp tục khám phá thêm thông tin về account ID

Kết quả

• Viết một script để tự động hóa quy trình này, nhờ đó có thể tìm AWS account ID của bucket một cách đáng tin cậy.
• Thực hiện tìm kiếm nhị phân cho từng chữ số để giảm số lượng phép thử cần thiết.

Tăng tốc

• Điều chỉnh VPC endpoint policy để giảm thời gian cần thiết cho policy có hiệu lực và cho việc chờ kết quả riêng lẻ trong CloudTrail.
• Nhờ đó rút ngắn thời gian tìm account ID xuống còn dưới 10 phút.

Ý kiến

• Bài viết blog này được đăng sau khi đã trao đổi với đội ngũ bảo mật AWS.
• Đã có một cuộc thảo luận thú vị về việc liệu AWS account ID có nên được xem là thông tin nhạy cảm hay không.
• Kỹ thuật này có thể áp dụng cho các dịch vụ khác ngoài S3.
• Những kỹ thuật như vậy khả thi vì có thể dùng điều kiện StringLike cho s3:ResourceAccount.
• Sẽ hữu ích nếu các sự kiện bị từ chối bởi VPC endpoint policy được ghi log trong CloudTrail.

Lời cảm ơn

• Kỹ thuật gốc của Ben Bridt là nguồn cảm hứng cho công việc này.
• Cảm ơn Chris Farris vì sự hỗ trợ và lời khuyên.

Ý kiến của GN⁺

• Kỹ thuật này có thể rất hữu ích khi thực hiện kiểm toán bảo mật trong môi trường đám mây, đặc biệt là để xác minh quyền sở hữu của AWS S3 bucket.
• Cuộc thảo luận về mức độ nhạy cảm của thông tin mà kỹ thuật này cung cấp phản ánh cuộc đối thoại liên tục về bảo mật dữ liệu và quyền riêng tư giữa nhà cung cấp dịch vụ đám mây và người dùng.
• Một công cụ khác cung cấp chức năng tương tự là dịch vụ CloudTrail của chính AWS, được dùng để ghi log và giám sát mọi hoạt động diễn ra trong môi trường AWS của người dùng.
• Trước khi áp dụng kỹ thuật này, người dùng cần bảo đảm nó phù hợp với chính sách của AWS và các thực hành bảo mật tốt nhất.
• Lợi ích của việc sử dụng kỹ thuật này là kiểm toán bảo mật hiệu quả và xác minh nhanh quyền sở hữu dữ liệu, nhưng cũng cần cân nhắc các rủi ro như khả năng lộ thông tin riêng tư.

[GN⁺]

Ý kiến Hacker News

• Khả năng áp dụng đối sánh ký tự đại diện cho khóa điều kiện s3:ResourceAccount của AWS

  • Điều đáng ngạc nhiên ở tính năng này là không có lý do chính đáng nào để cấp hoặc từ chối quyền dựa trên việc khớp một phần ID tài khoản. ID tài khoản AWS có thể nhạy cảm giống như địa chỉ IP, nhưng để công việc chạy được thì ai đó vẫn phải biết nó.

• ID tài khoản AWS == địa chỉ IP của bạn. Nó có thể nhạy cảm, nhưng để xử lý công việc thì ai đó phải biết nó.

  • Ví dụ: trong một giao dịch với bên thứ ba mà tác giả phải tích hợp do quy trình chống rửa tiền, tác giả muốn cấu hình privatelink vốn nhìn chung an toàn hơn so với một cổng sftp mở. Tuy nhiên, công ty đó đã từ chối với lý do bảo mật vì muốn che giấu ID tài khoản. Kết quả là nhóm của tác giả đã đưa dải IP công khai mà họ sử dụng vào whitelist cho cổng 22.
  • Bài học rút ra: che giấu ID có thể trông như một quyết định khôn ngoan, nhưng nếu không có một địa chỉ để người khác liên hệ với bạn thì trên thực tế bạn không thể vận hành công việc kinh doanh.

• Thông thường bạn sẽ không phát tán công khai ID tài khoản, nhưng đến một thời điểm nào đó bạn nên kỳ vọng rằng một phần của nó sẽ bị lộ ra.

  • Khi các nhà cung cấp bên thứ ba và nền tảng SaaS chuyển sang các kiểu tích hợp ưu tiên giả định vai trò (role assumption) thay vì người dùng IAM và access key, thì ID tài khoản của tài khoản được dùng làm điểm tích hợp sẽ được phía bên kia biết đến, và họ cũng có các phụ thuộc cùng lỗ hổng của riêng họ.

• Các tài nguyên AWS công khai khác có không gian tên toàn cục cũng làm lộ ID tài khoản AWS.

  • Với những ai quan tâm, đoạn mã đó đã được đăng trực tuyến tại đây: find-s3-account

• Liên quan: AWS key ID (không phải phần secret key) có chứa ID tài khoản, chỉ là bị dịch bit đi một vị trí.

  • Key ID này được đưa vào URL của các liên kết presigned tới S3, nên rất có thể bạn đã công khai ID tài khoản của mình rồi.

• Một phát hiện thú vị, nhưng nhìn tiêu đề tôi đã kỳ vọng sẽ có một cách đơn giản hơn.

  • Tôi ước AWS có một cách đơn giản để hỏi bằng tài khoản quản trị kiểu như "tài nguyên X đang ở đâu". Đặc biệt là cần một chức năng nhanh chóng cho biết một bucket S3 cụ thể thuộc tài khoản nào. Điều này chủ yếu là vấn đề với các bucket cũ tồn tại từ trước khi mọi thứ được định nghĩa bằng code. Khi bạn có nhiều tài khoản AWS, việc đi tìm tài nguyên trong các tài khoản và khu vực có thể có mà chưa biết trước sẽ khá phiền phức.

• Những tình huống mà việc hack thực sự gợi lại kiểu sáo mòn hay hiểu lầm cũ như "hack" mật khẩu từng ký tự một luôn rất thú vị.

• Vector tấn công đáng lo hơn là giờ đây có thể dùng số tài khoản để thử thêm principal của tài khoản khác vào allowlist trong policy của chính tài khoản mình.

  • Nếu principal đó không tồn tại ở tài khoản kia, sẽ xuất hiện lỗi không tìm thấy role/user. Có thể lợi dụng điều này để tìm ra principal thực sự của tài khoản khác.

• Tại sao điều này lại quan trọng? Một điều hiển nhiên là: nếu đã biết bucket production, bạn có thể tìm ra bucket development thuộc cùng tổ chức, đây là hành vi ngoài dự kiến.