Bucketsquatting S3 (akhirnya) menghilang

• AWS memperkenalkan fitur perlindungan namespace berbasis akun baru untuk mengatasi masalah S3 bucketsquatting
• Namespace baru ini menggunakan format <prefix>-<accountid>-<region>-an, sehingga hanya akun yang sama yang dapat membuat bucket dengan nama tersebut
• Jika akun lain mencoba menggunakan nama yang sama, akan muncul error InvalidBucketNamespace, dan error yang sama juga dikembalikan jika region yang ditentukan salah
• Namespace ini direkomendasikan untuk digunakan secara default, dan dapat dipaksakan melalui kebijakan organisasi (SCP) dengan condition key s3:x-amz-bucket-namespace
• Ini tidak berlaku surut untuk bucket yang sudah ada, tetapi memberikan perlindungan kuat untuk bucket baru, yang berarti perbaikan mendasar pada arsitektur keamanan S3

---

Ringkasan masalah bucketsquatting

• Bucketsquatting (atau Bucketsniping) adalah bentuk serangan di AWS S3 yang memanfaatkan fakta bahwa nama bucket harus unik secara global
  • Saat sebuah bucket dihapus, namanya kembali tersedia, sehingga penyerang dapat mendaftarkan bucket baru dengan nama yang sama
  • Hal ini dapat menimbulkan risiko akses ke data sensitif atau gangguan layanan
• Organisasi sering menggunakan aturan penamaan yang mudah ditebak seperti myapp-us-east-1, sehingga meningkatkan paparan terhadap serangan
• Tim internal AWS juga terdampak oleh masalah ini, dan selama sekitar 10 tahun telah bekerja sama dengan tim keamanan AWS untuk mencari solusi

Pengenalan namespace S3 baru

• Untuk menyelesaikan masalah ini, AWS memperkenalkan konsep account namespace
  • Format: <prefix>-<accountid>-<region>-an
  • Contoh: myapp-123456789012-us-west-2-an
• Namespace ini membatasi agar hanya akun terkait yang dapat membuat bucket dengan nama tersebut
  • Jika akun lain membuat nama yang sama, akan muncul error InvalidBucketNamespace
  • Jika region pada nama bucket tidak cocok dengan region sebenarnya, error yang sama juga dikembalikan
• AWS merekomendasikan penggunaan namespace ini secara default untuk semua bucket baru
  • Berbeda dari namespace yang sudah ada (.mrap, --x-s3, -s3alias), kali ini namespace diperkenalkan sebagai namespace untuk pengguna umum dengan tujuan keamanan

Penerapan dan pengelolaan kebijakan

• Administrator keamanan dapat menggunakan condition key s3:x-amz-bucket-namespace untuk memaksakan penggunaan namespace melalui kebijakan organisasi menyeluruh (SCP)
• Ini tidak diterapkan otomatis pada bucket yang sudah ada atau template tanpa namespace
  • Untuk melindungi bucket lama, Anda perlu membuat bucket dengan format namespace baru dan memigrasikan data
• Dengan langkah ini, bucketsquatting pada praktiknya sedang “menghilang”, dan bucket baru mendapatkan perlindungan penuh

Pendekatan penyedia cloud lain

• Google Cloud Storage (GCS) sudah menggunakan namespace berbasis verifikasi nama domain
  • Bucket dengan format domain seperti myapp.com hanya bisa dibuat oleh pemilik domain
  • Pada bucket non-domain, kemungkinan bucketsquatting masih tetap ada
• Azure Blob Storage menggunakan struktur nama storage account + nama container
  • Dengan batas maksimum 24 karakter, namespace-nya lebih sempit sehingga bisa lebih rentan terhadap masalah yang sama

Kesimpulan (tl;dr)

• AWS S3 memperkenalkan namespace akun-region baru
• Namespace ini mencegah serangan bucketsquatting dan sangat direkomendasikan saat membuat bucket baru
• Bucket lama tidak terlindungi otomatis, sehingga bila perlu perlindungan harus diperkuat melalui migrasi data

[GN⁺]

Opini Hacker News

• Baru-baru ini mengetahui bahwa alamat email pengguna root tidak bisa digunakan kembali bahkan setelah akun AWS dihapus
  Seseorang di organisasi kami membuat pengguna root untuk akun yang sudah ditutup memakai email utama perusahaan, lalu membuat akun baru dengan email lain, dan sekarang masa pemulihan setelah penghapusan pun sudah lewat
  Akibatnya, email tersebut terikat permanen ke akun root yang sudah dihapus, sehingga login SSO melalui IdP eksternal menjadi tidak mungkin
  Sudah menghubungi dukungan AWS, tetapi hampir tidak mendapat bantuan

  • Saat baru-baru ini membantu dukungan pelanggan, saya menemui kasus di mana MFA akun root tetap terhubung ke ponsel mantan engineer utama setelah ia keluar dari perusahaan
    Kata sandinya terdokumentasi, tetapi tidak ada cara untuk menonaktifkan MFA, jadi kami menghubungi dukungan AWS, account manager, dan lain-lain, namun tidak ada solusi
    Pada akhirnya akses ke akun root tetap terkunci, dan kami mungkin harus memindahkan seluruh lingkungan yang kompleks ke akun baru
  • Jika penyedia email mendukungnya, Anda bisa memanfaatkan plus addressing
    AWS menganggap email dengan tanda plus sebagai alamat yang berbeda
  • Jangan gunakan akun root untuk aktivitas manusia; buatlah sebagai akun khusus untuk keadaan darurat dan simpan kredensialnya dengan aman
    Sebaiknya hanya digunakan saat benar-benar ada masalah serius
  • Ini kembali mengingatkan betapa rapuhnya keamanan
    Pada akhirnya, jika ada phisher yang menipu tim dukungan pelanggan dan mendapat skor evaluasi 10/10, semuanya bisa runtuh
  • Jika email dari IdP dipetakan ke role, saya penasaran apa maksud dari “terikat permanen ke akun root yang sudah dihapus”
    Saya ingin tahu mekanisme apa yang sebenarnya mencegah penggunaan

• Tampaknya penulis salah memahami konsep account name di Azure Blob Storage
  Pada dasarnya itu setara dengan nama bucket di S3, dan tetap harus unik secara global, jadi masih sangat merepotkan
  Terutama karena panjang namanya dibatasi 24 karakter, jadi makin menyebalkan
  Saya berharap Microsoft juga memperkenalkan namespace per pelanggan seperti AWS

  • Sekitar 10 tahun lalu, tim S3 juga sudah menyadari masalah ini
    Tetapi karena keterbatasan desain awal, mereka tidak bisa mengubahnya
    Secara pribadi saya tidak paham mengapa mereka belum juga membuat API S3 v2
    Mereka sebenarnya bisa mendorong migrasi bertahap dengan API baru, tetapi pada akhirnya baik pelanggan maupun engineer sama-sama menanggung penderitaan yang tidak perlu
  • Saat pertama kali memakai Azure, saya merasa ini desain yang aneh ketika melihat resource tidak diberi namespace per akun
  • Penulisnya sendiri muncul dan mengatakan bahwa ia telah memperbarui tulisannya dengan memasukkan masukan yang diterima
  • Batasan nama bukan cuma 24 karakter, tetapi juga tidak boleh memakai tanda hubung, underscore, atau titik
    Jadi Anda hanya bisa memakai angka dan huruf kecil, yang sangat tidak nyaman
    Akan lebih baik jika setidaknya mengizinkan dash seperti S3 atau GCS
  • Tidak bisa memakai bahkan tanda hubung dalam nama storage account menurut saya benar-benar desain yang berantakan
    Resource lain seperti container registry juga sama

• Untuk nama paket, nama bucket, nama akun GitHub, dan sejenisnya, saya pernah berpikir format seperti Discord @nama-4digitacak mungkin masuk akal
  Dengan begitu, ruang nama jadi lebih demokratis dan squatting atau serangan reuse bisa dicegah
  Saat akun dihapus, seluruh nama bisa dipensiunkan sehingga rapi

  • Namun, Discord menghapus format ini dua tahun lalu dan beralih ke sistem nama unik global
    Alasannya dijelaskan dalam pengumuman resmi,
    yaitu karena harus mengingat empat digit angka dan bahkan membedakan huruf besar-kecil terasa merepotkan
  • Secara pribadi saya merasa sistem UUID + petname lebih baik
    Khususnya di aplikasi chat, lebih rapi jika memakai ID internal di balik layar dan pengguna hanya memakai alias
    Untuk bucket, karena nama yang mudah dibaca manusia itu penting, saya justru merasa lebih baik memakai domain milik sendiri
  • Untuk bucket mungkin masuk akal, tetapi untuk mencegah package hijacking, kode 4 digit tidak terlalu membantu
    Malah hanya menambah risiko typo
  • Akan menyenangkan jika kita bisa memakai nama berbasis verifikasi domain (@example.com) di mana saja
  • Saat membuat tool internal, saya memberi pengguna ID internal yang opaque dan membiarkan nama mereka diubah dengan bebas
    Di komunitas online, nama yang bentrok itu hal yang wajar,
    jadi saya mempertanyakan mengapa kita harus memaksakan nama unik global

• Terima kasih kepada Ian Mckay yang menulis artikel ini
  AWS secara resmi memperkenalkan namespace per akun dan per region, dan itu perubahan yang bagus
  Akan lebih baik jika tool IaC seperti Terraform mengadopsi aturan ini sebagai default
  Terraform sendiri sudah menambahkan sufiks hash acak di akhir nama bucket untuk mencegah konflik
  Blog resmi AWS juga membahas hal ini

• Menarik bahwa penyedia cloud bisa terkena serangan bucket squatting ketika memakai nama bucket yang dapat diprediksi untuk scratch space internal
  Di AWS, serangan nyata sulit dilakukan karena ada hash, tetapi GCP bahkan baru-baru ini masih mengalami masalah seperti ini
  Presentasi terkait: DC32 AWS bucket squatting talk,
  kerentanan GCP: CVE-2026-1727

  • Presentasi itu benar-benar mengesankan
    Begitu melihat bahwa nama bucket bisa diprediksi, saya langsung merasa ini berbahaya
    Kombinasi bucket squatting + bucket publik + masalah TOCTOU di CloudFormation
    sudah cukup untuk menyebarkan resource ke akun lain
    Mengejutkan bahwa tim keamanan AWS tidak menemukan ini lebih awal

• Nama DNS juga punya masalah serupa
  Jika domain tidak diperpanjang, domain itu bisa didaftarkan ulang,
  dan seseorang bisa memasang MX record untuk mencegat email reset kata sandi dan sejenisnya

  • Ada juga kasus aset seperti blok IPv4 legacy berhasil direbut kembali dengan cara seperti ini

• Bucket AWS masih hanya memberikan fitur khusus jika namanya sama dengan hostname
  Dokumentasi terkait: Virtual Hosting in S3

• Sebuah nama tidak boleh identik dengan objek yang dirujuknya
  Jika nama digunakan ulang, ia akan merujuk ke objek yang sama sekali berbeda,
  dan maknanya bergantung pada konteks
  Hanya ketika Anda sendiri yang menetapkan ulang nama itu, ia bisa dianggap tetap sama

• Saya penasaran apakah membuka account ID ke publik berisiko dari sisi keamanan

  • AWS secara resmi menyatakan bahwa account ID bukan informasi rahasia
    Menurut dokumentasi resmi,
    ini tetap harus ditangani dengan hati-hati, tetapi tidak dianggap sebagai informasi sensitif
  • Menurut saya pribadi, ini seperti alamat email: pengenal, bukan sarana autentikasi
    Selama tidak terlalu diumbar, mestinya tidak masalah
  • Dari sisi hygiene memang kurang ideal, tetapi account ID saja tidak cukup untuk menyerang
    Dalam aturan IAM, penyerang bisa memakai * , jadi pada akhirnya yang penting adalah bagaimana pihak bertahan menyetel kebijakan
  • Jika Anda membagikan URL bertanda tangan S3, di dalamnya terdapat Access Key ID
    Jika didekode dengan base32, Account ID bisa diekstrak
    Referensi: tulisan analisis terkait

• Bahwa S3 menggunakan nama bucket saja sebagai kunci akses adalah salah satu keputusan desain yang paling menjengkelkan