- AWS đã giới thiệu tính năng bảo vệ namespace dựa trên tài khoản mới để giải quyết vấn đề S3 bucketsquatting
- Namespace mới có dạng
<prefix>-<accountid>-<region>-an, trong đó chỉ cùng một tài khoản mới có thể tạo bucket với tên đó
- Nếu tài khoản khác cố dùng cùng tên, sẽ phát sinh lỗi
InvalidBucketNamespace; chỉ định sai region cũng trả về cùng lỗi này
- Namespace này được khuyến nghị sử dụng mặc định và có thể được áp dụng bắt buộc trong chính sách tổ chức (SCP) bằng khóa điều kiện
s3:x-amz-bucket-namespace
- Dù không được áp dụng hồi tố cho bucket hiện có, nó mang lại lớp bảo vệ mạnh cho bucket mới, đồng nghĩa với một cải tiến mang tính nền tảng trong kiến trúc bảo mật S3
Tổng quan về vấn đề Bucketsquatting
- Bucketsquatting (hoặc Bucketsniping) là một hình thức tấn công lợi dụng việc tên bucket trong AWS S3 phải là duy nhất trên toàn cục
- Khi bucket bị xóa, tên đó lại có thể được dùng lại, và kẻ tấn công có thể đăng ký một bucket mới với đúng tên đó
- Điều này có thể dẫn đến rủi ro truy cập dữ liệu nhạy cảm hoặc gián đoạn dịch vụ
- Các tổ chức thường dùng quy ước đặt tên dễ đoán như
myapp-us-east-1, làm tăng khả năng bị tấn công
- Ngay cả các nhóm nội bộ AWS cũng từng bị ảnh hưởng bởi vấn đề này và đã phối hợp với đội ngũ bảo mật AWS suốt khoảng 10 năm để tìm cách giải quyết
Giới thiệu namespace S3 mới
- AWS đã đưa vào khái niệm namespace theo tài khoản (account namespace) để giải quyết vấn đề
- Định dạng:
<prefix>-<accountid>-<region>-an
- Ví dụ:
myapp-123456789012-us-west-2-an
- Namespace này giới hạn để chỉ tài khoản đó mới có thể tạo bucket với tên tương ứng
- Nếu tài khoản khác tạo cùng tên, sẽ xuất hiện lỗi
InvalidBucketNamespace
- Nếu region trong tên bucket không khớp với region thực tế, cũng sẽ trả về cùng lỗi đó
- AWS khuyến nghị dùng namespace này mặc định cho mọi bucket mới
- Khác với các namespace hiện có như
.mrap, --x-s3, -s3alias, lần này đây là namespace dành cho người dùng phổ thông với mục đích bảo mật
Áp dụng và quản lý chính sách
- Quản trị viên bảo mật có thể dùng khóa điều kiện
s3:x-amz-bucket-namespace để bắt buộc sử dụng namespace trên chính sách toàn tổ chức (SCP)
- Việc này không tự động áp dụng cho bucket hiện có hoặc các template không có namespace
- Để bảo vệ bucket hiện tại, cần tạo bucket theo định dạng namespace mới rồi di chuyển dữ liệu sang
- Nhờ thay đổi này, bucketsquatting về thực chất đang “biến mất”, và các bucket mới sẽ được bảo vệ hoàn toàn
Cách tiếp cận của các nhà cung cấp đám mây khác
- Google Cloud Storage (GCS) đã sử dụng namespace dựa trên xác minh tên miền
- Bucket có dạng tên miền như
myapp.com chỉ có chủ sở hữu tên miền mới được tạo
- Với bucket không theo dạng tên miền, vẫn còn khả năng xảy ra bucketsquatting
- Azure Blob Storage dùng cấu trúc tên tài khoản lưu trữ + tên container
- Vì giới hạn tối đa 24 ký tự nên namespace hẹp hơn, có thể dễ bị vấn đề tương tự hơn
Kết luận (tl;dr)
- AWS S3 đã có namespace tài khoản-region mới
- Namespace này ngăn chặn tấn công bucketsquatting và được khuyến nghị phải dùng khi tạo bucket mới
- Bucket hiện có không được bảo vệ tự động, nên nếu cần thì phải tăng cường bảo vệ thông qua di chuyển dữ liệu
1 bình luận
Ý kiến trên Hacker News
Gần đây tôi mới biết rằng địa chỉ email người dùng root không thể được tái sử dụng ngay cả sau khi tài khoản AWS đã bị xóa
Một người trong tổ chức của chúng tôi đã tạo người dùng root cho một tài khoản đã đóng bằng email chính của công ty, rồi tạo tài khoản mới bằng email khác, nhưng giờ thì thời gian khôi phục sau khi xóa cũng đã trôi qua
Kết quả là email đó bị gắn vĩnh viễn với tài khoản root đã bị xóa, nên không thể đăng nhập SSO thông qua IdP bên ngoài
Chúng tôi đã liên hệ bộ phận hỗ trợ AWS nhưng hầu như không nhận được trợ giúp nào
Mật khẩu thì đã được ghi lại trong tài liệu, nhưng không có cách nào để gỡ MFA, nên chúng tôi đã liên hệ AWS Support, quản lý tài khoản và nhiều bên khác nhưng vẫn không giải quyết được
Kết quả là hiện giờ không thể truy cập tài khoản root, và có thể sẽ phải chuyển cả một môi trường phức tạp sang tài khoản mới
AWS coi email có dấu cộng là một địa chỉ riêng biệt
Tốt nhất chỉ nên dùng khi xảy ra vấn đề thực sự nghiêm trọng
Cuối cùng chỉ cần một kẻ lừa đảo qua mặt được bộ phận hỗ trợ khách hàng và nhận đánh giá 10 điểm là mọi thứ có thể sụp đổ
Tôi muốn biết cơ chế nào đang thực sự ngăn việc sử dụng
Có vẻ tác giả đã hiểu sai khái niệm account name của Azure Blob Storage
Về bản chất nó ở cùng cấp với tên bucket của S3, vẫn phải là duy nhất trên toàn cục nên vẫn rất bất tiện
Đặc biệt giới hạn độ dài chỉ 24 ký tự khiến mọi thứ còn khó chịu hơn
Tôi mong Microsoft cũng đưa vào namespace theo từng khách hàng giống AWS
Nhưng họ không thể thay đổi vì các ràng buộc từ thiết kế ban đầu
Cá nhân tôi không hiểu vì sao đến giờ họ vẫn chưa tạo S3 v2 API
Họ hoàn toàn có thể dùng API mới để thúc đẩy quá trình di trú dần dần, nhưng cuối cùng cả khách hàng lẫn kỹ sư đều đang phải chịu đựng đau khổ không cần thiết
nên chỉ được dùng số và chữ thường, điều này quá bất tiện
Giá như nó cho phép ít nhất là dấu gạch ngang như S3 hay GCS
Các tài nguyên khác như container registry cũng tương tự
Tôi từng nghĩ các tên như package name, bucket name hay GitHub account name có thể dùng định dạng @tên-4số_ngẫu_nhiên như Discord
Cách này có thể dân chủ hóa không gian tên và ngăn squatting hoặc tấn công tái sử dụng
Khi tài khoản bị xóa thì chỉ cần loại bỏ toàn bộ tên đó là xong, khá gọn gàng
Lý do được giải thích trong thông báo chính thức,
vì việc phải nhớ 4 chữ số và còn phải phân biệt chữ hoa chữ thường là rất bất tiện
Đặc biệt với ứng dụng chat, sẽ gọn gàng hơn nếu dùng ID nội bộ và để người dùng chỉ dùng biệt danh
Với bucket thì tên dễ đọc cho con người mới là cốt lõi, nên tôi nghĩ tốt hơn là dùng chính domain của mình
Ngược lại nó chỉ làm tăng rủi ro gõ nhầm
Việc trùng tên trong cộng đồng trực tuyến là điều rất tự nhiên,
nên tôi không hiểu vì sao cứ phải ép buộc tên duy nhất toàn cục
Cảm ơn Ian Mckay, tác giả bài viết
Việc AWS chính thức đưa vào namespace theo account và region là một thay đổi tích cực
Sẽ còn tốt hơn nếu các công cụ IaC như Terraform áp dụng quy tắc này làm mặc định
Hiện tại Terraform đã gắn hậu tố hash ngẫu nhiên vào cuối tên bucket để tránh xung đột
Blog chính thức của AWS cũng có nội dung liên quan
Điều thú vị là các nhà cung cấp cloud dùng tên bucket có thể đoán trước cho không gian scratch nội bộ, từ đó dẫn tới tấn công bucket squatting
Trên AWS thì việc tấn công thực tế khó hơn do có hash, nhưng GCP gần đây vẫn gặp vấn đề kiểu này
Tham khảo: DC32 AWS bucket squatting talk,
lỗ hổng GCP: CVE-2026-1727
Ngay khi thấy tên bucket có thể đoán được, tôi đã cảm nhận được rủi ro
Với tổ hợp bucket squatting + bucket công khai + vấn đề TOCTOU của CloudFormation,
hoàn toàn có thể triển khai tài nguyên sang tài khoản khác
Thật đáng ngạc nhiên là đội bảo mật AWS đã không phát hiện điều này sớm hơn
Tên DNS cũng có vấn đề tương tự
Nếu không gia hạn domain, người khác có thể đăng ký lại,
rồi cấu hình MX record để chặn các email đặt lại mật khẩu chẳng hạn
Bucket AWS vẫn chỉ cung cấp các tính năng đặc biệt khi tên của nó trùng với hostname
Tài liệu liên quan: Virtual Hosting in S3
Tên không nên đồng nhất với chính đối tượng mà nó chỉ tới
Khi tên được tái sử dụng, nó sẽ trỏ tới một đối tượng hoàn toàn khác,
và ý nghĩa của nó thay đổi theo ngữ cảnh
Chỉ khi bạn tự gán lại cái tên đó thì mới có thể xem là cùng một thứ
Tôi từng thắc mắc liệu việc công khai account ID có gây rủi ro bảo mật không
Theo tài liệu chính thức,
cần được xử lý cẩn thận nhưng không bị xem là thông tin nhạy cảm
Miễn là không phơi bày quá mức thì vẫn ổn
Trong quy tắc IAM, kẻ tấn công có thể dùng *, nên cuối cùng điều quan trọng vẫn là chính sách phòng thủ được cấu hình thế nào
Nếu giải mã nó bằng base32 thì có thể trích xuất Account ID
Tham khảo: bài phân tích liên quan
Việc S3 chỉ dùng tên bucket làm khóa truy cập vẫn là một trong những quyết định thiết kế gây khó chịu nhất