Cara Menemukan ID Akun AWS dari Bucket S3 Apa Pun

Menemukan ID Akun AWS dari Bucket S3

• Pada 2021, Ben Bridts mempublikasikan metode kreatif untuk menemukan ID akun AWS dari bucket S3 yang terekspos.
• Artikel ini menjelaskan teknik untuk menemukan ID akun dari bucket S3 privat maupun publik.

Dari Bucket S3 ke ID Akun AWS

• Menunjukkan teknik untuk menemukan ID akun AWS yang sebelumnya tidak diketahui dari bucket bernama bucket-alpha melalui output shell.

Bagaimana tepatnya teknik ini bekerja?

• Menganalisis alasan teknik Ben dapat bekerja dengan menggabungkan tiga elemen kunci:
  • Kemampuan menerapkan kebijakan IAM pada permintaan
  • Kemampuan menyimpulkan apakah kebijakan IAM mengizinkan permintaan tersebut atau tidak
  • Kemampuan menerapkan pencocokan wildcard pada kunci kondisi s3:ResourceAccount

Solusi

• Ditemukan solusi yang memanfaatkan VPC endpoint untuk S3 dan perbedaan perilaku di CloudTrail saat permintaan ditolak.

Melihat langkah demi langkah

• Prosedur langkah demi langkah saat ingin menemukan ID akun dari bucket bucket-alpha:
  • Menentukan region bucket
  • Mendeploy VPC dan VPC endpoint di region yang sama
  • Menjalankan instance EC2 di dalam VPC dan memastikan penggunaan VPC endpoint untuk S3
  • Mengubah kebijakan VPC endpoint untuk menentukan apakah ID akun bucket target dimulai dengan "0"
  • Mengirim permintaan ke bucket target
  • Memeriksa apakah permintaan muncul di CloudTrail
  • Berdasarkan hasilnya, mengubah kebijakan VPC endpoint untuk menemukan informasi lebih lanjut tentang ID akun

Hasil

• Menulis skrip untuk mengotomatisasi proses ini sehingga ID akun bucket dapat ditemukan dengan andal.
• Melakukan binary search untuk setiap digit guna mengurangi jumlah pengujian yang diperlukan.

Peningkatan kecepatan

• Mengubah kebijakan VPC endpoint untuk mengurangi waktu yang dibutuhkan agar kebijakan berlaku dan waktu menunggu hasil satu per satu di CloudTrail.
• Dengan ini, waktu yang dibutuhkan untuk menemukan ID akun dapat dipersingkat menjadi kurang dari 10 menit.

Opini

• Tulisan blog ini dipublikasikan setelah berdiskusi dengan tim keamanan AWS.
• Ada diskusi menarik tentang apakah ID akun AWS seharusnya dianggap sebagai informasi sensitif.
• Teknik ini mungkin juga dapat diterapkan ke layanan lain selain S3.
• Teknik ini dimungkinkan karena kondisi StringLike dapat digunakan untuk s3:ResourceAccount.
• Mungkin akan bermanfaat jika event yang ditolak oleh kebijakan VPC endpoint juga dicatat di CloudTrail.

Ucapan terima kasih

• Teknik asli dari Ben Bridt menjadi inspirasi untuk pekerjaan ini.
• Terima kasih atas bantuan dan saran dari Chris Farris.

Opini GN⁺

• Teknik ini bisa sangat berguna untuk melakukan audit keamanan di lingkungan cloud, khususnya untuk memverifikasi kepemilikan bucket AWS S3.
• Diskusi tentang sensitivitas informasi yang diberikan teknik ini mencerminkan percakapan berkelanjutan antara penyedia layanan cloud dan pengguna mengenai keamanan data dan privasi.
• Alat lain yang menyediakan fungsi serupa adalah layanan milik AWS sendiri, CloudTrail, yang digunakan untuk mencatat dan memantau seluruh aktivitas yang terjadi di lingkungan AWS pengguna.
• Sebelum mengadopsi teknik ini, pengguna harus memastikan bahwa teknik tersebut selaras dengan kebijakan AWS dan praktik terbaik keamanan.
• Manfaat yang bisa diperoleh dari penggunaan teknik ini adalah audit keamanan yang efisien dan verifikasi kepemilikan data yang cepat, tetapi risiko seperti potensi paparan informasi pribadi juga perlu dipertimbangkan.

[GN⁺]

Komentar Hacker News

• Kemampuan untuk menerapkan pencocokan wildcard pada kunci kondisi s3:ResourceAccount milik AWS

  • Hal yang mengejutkan dari fitur ini adalah tidak ada alasan yang masuk akal untuk memberikan atau menolak izin berdasarkan kecocokan sebagian ID akun. ID akun AWS mungkin sensitif seperti alamat IP, tetapi agar pekerjaan bisa berjalan, seseorang tetap perlu mengetahuinya.

• ID akun AWS == alamat IP Anda. Bisa jadi sensitif, tetapi untuk menyelesaikan pekerjaan, seseorang harus mengetahuinya.

  • Contoh: penulis menginginkan pengaturan privatelink yang umumnya lebih aman daripada port sftp terbuka, dalam transaksi dengan pihak ketiga yang harus diintegrasikan karena prosedur anti pencucian uang. Namun, perusahaan tersebut menolak dengan alasan keamanan karena ingin menyembunyikan ID akun mereka. Akibatnya, tim penulis memasukkan rentang IP publik yang mereka gunakan ke whitelist pada port 22.
  • Pelajaran dari cerita ini: menyembunyikan ID mungkin terlihat bijak, tetapi jika tidak ada alamat yang bisa dipakai orang untuk menghubungi Anda, Anda sebenarnya tidak bisa menjalankan bisnis.

• Secara umum saya tidak akan mendistribusikan ID akun secara publik, tetapi pada titik tertentu Anda harus menganggap sebagian darinya akan terekspos.

  • Seiring vendor pihak ketiga dan platform SaaS beralih ke metode integrasi yang lebih memilih role assumption daripada pengguna IAM dan access key, ID akun dari akun yang digunakan sebagai titik integrasi akan diketahui oleh pihak lain, dan mereka memiliki dependensi serta kerentanan mereka sendiri.

• Sumber daya AWS publik lain yang memiliki namespace global juga mengungkap ID akun AWS.

  • Bagi yang tertarik, kode tersebut dipublikasikan secara online di sini: find-s3-account

• Terkait: AWS key ID (bukan bagian secret key) berisi ID akun, hanya digeser satu posisi bit.

  • Key ID ini disertakan dalam URL tautan yang telah dipra-tandatangani untuk S3, jadi kemungkinan besar Anda sudah mengekspos ID akun tersebut.

• Penemuan yang menarik, tetapi saat melihat judulnya saya berharap akan ada cara yang lebih sederhana.

  • Akan bagus jika ada cara sederhana untuk bertanya ke AWS, dari akun admin, “di mana resource X berada”. Secara khusus, diperlukan fungsi yang bisa dengan cepat memberi tahu akun mana yang memiliki bucket S3 tertentu. Ini terutama masalah yang berkaitan dengan bucket lama yang sudah ada sebelum didefinisikan lewat kode. Ketika Anda memiliki banyak akun AWS, mencari resource di akun yang tidak diketahui dan kemungkinan region yang mungkin ada bisa sangat merepotkan.

• Skenario ketika peretasan sungguhan menghadirkan kembali klise atau kesalahpahaman lama tentang “meretas” kata sandi satu karakter pada satu waktu selalu menarik.

• Vektor serangan yang lebih mengkhawatirkan adalah saat nomor akun kini dapat digunakan untuk mencoba menambahkan principal dari akun lain ke allowlist dalam kebijakan akun Anda sendiri.

  • Jika principal tersebut tidak ada di akun lain, akan muncul kesalahan bahwa role/pengguna tidak dapat ditemukan. Ini bisa dimanfaatkan untuk menemukan principal nyata di akun lain.

• Mengapa ini penting? Satu hal yang jelas: jika diberikan bucket produksi, orang bisa menemukan bucket pengembangan milik organisasi yang sama, dan itu merupakan perilaku yang tidak terduga.