Akun Diambil Alih Setelah Gangguan AWS

Baru-baru ini, setelah gangguan layanan di AWS terjadi, seorang pengguna melaporkan insiden di mana akun AWS-nya diambil alih oleh penyerang eksternal

Jalur kompromi dan kondisi masalah

• Disebutkan bahwa selama masa gangguan, beberapa kebijakan keamanan mungkin tidak berfungsi secara normal
• Penyerang meninggalkan jejak akses tidak biasa pada log akun setelah gangguan, dan terjadi fenomena pembuatan/penghapusan sumber daya yang tidak terduga
• Pengguna mengungkapkan kekhawatiran akan kemungkinan perubahan hak akses atau paparan kredensial autentikasi bersama-sama dengan gangguan

Dampak dan respons

• Terjadi kerugian nyata seperti kenaikan biaya, kebocoran data, dan lain-lain
• Pengguna menghubungi tim dukungan AWS untuk menanyakan riwayat insiden dan cara respons
• Komunitas menekankan pentingnya pencegahan sebelumnya, seperti mengaktifkan autentikasi dua faktor dan pembatasan akses berbasis peran sebagai langkah-prioritas

[GN⁺]

Komentar Hacker News

• Biasanya kejadian seperti ini dianggap kebetulan, tapi saya juga pernah mengalami kasus akun klien yang dikompromikan. Pelanggan itu organisasi kecil, dan tiba-tiba muncul jejak login konsol dan perubahan password pada dua akun IAM lama yang sudah tidak digunakan lebih dari 5 tahun. Hasil penyelidikan sampai saat ini menunjukkan bahwa yang terungkap hanya adanya tiket dukungan untuk mengaktifkan akses produksi AWS SES dan menaikkan batas email harian menjadi 50 ribu. Sangat aneh karena akun yang menganggur lebih dari 5 tahun tiba-tiba aktif tepat pada titik ini.

  • Terlihat seperti serangan phishing. Contohnya, menerima email yang mengaku sebagai pengumuman gangguan AWS, lalu mengarahkan untuk login konsol; jika autentikasi lewat wrapper berbahaya, keamanan akun bisa ditembus.
  • Saya pernah mengalami kejadian yang hampir sama setahun yang lalu. Login dengan akun yang sangat lama, akses SES, lalu permintaan kenaikan batas email. Kami bisa merespons cepat karena tiket kenaikan batas itu memang wajib. Kalau belum diperiksa, periksa juga role yang baru dibuat. Kami langsung menutup akun yang terkompromi, dan saat saya meninjau semua role, saya menghapus semua role yang berusia kurang dari sebulan atau yang punya hak admin. Di sisi lain, kami juga mengonfirmasi bahwa komprominya memang dimulai dari kunci saya sendiri. Waktu user pertama dibuat hampir sebulan sebelum permintaan SES yang sebenarnya, sehingga kemungkinan penyerang sudah menginfeksi kami lalu memanfaatkan saat AWS bermasalah. Inilah sebabnya kejadian ini bisa tidak terlihat karena menyatu dengan masalah AWS lainnya.

• Seseorang yang sudah mendapatkan akses mungkin menunggu insiden seperti kekacauan infrastruktur AWS lalu menyerang saat itu agar bisa bersembunyi di dalam kekacauan. Meskipun token bocor berminggu-minggu atau berbulan-bulan sebelumnya, mereka bisa memilih menunggu sampai ada insiden besar sebelum bertindak. Kalau saya penyerang, saya akan ingin mencoba metode ini.

  • Tentu saja mungkin. Sebagai orang yang biasa menangani due diligence, saya juga benar-benar pernah dengar kasus semacam ini. Penyerang sering menyiapkan semuanya sebelumnya lalu menunggu hingga ada acara besar seperti akuisisi perusahaan untuk mulai bergerak. Penyerang yang lebih canggih cenderung menunggu peluang semacam ini secara proaktif.
  • Sebagai anggota tim yang sama, saya ingin menambahkan bahwa dua tahun lalu saya menerima email peringatan dari orang acak terkait kunci yang hari ini digunakan untuk disalahgunakan. Tapi sampai kemarin tidak ada penyalahgunaan apa pun.
  • Justru saya rasa ini waktu yang buruk untuk menyerang. Semua orang sedang fokus pada AWS dan banyak yang login, jadi jika ada sesuatu yang aneh kemungkinan akan lebih cepat terlihat. Kalau perusahaan kami pakai AWS, dalam situasi ini kami akan jauh lebih waspada terhadap semuanya.

• Kalau saya penyerang, saat mana yang saya pilih? Gangguan besar di mana agregasi log pun tidak berfungsi dengan baik bisa jadi peluang bagus. Bisa jadi ini dieksploitasi pada momen ini karena kompromi sudah terjadi, atau penyerang memanfaatkan gangguan AWS untuk melakukan serangan lain melalui resource milik saya.

• Di lingkungan cloud, kalau ada resource yang aneh (misalnya EC2) terbentuk, kamu bisa cek di CloudTrail untuk melihat event apa yang memicunya. Sebagai contoh, event RunInstances.

  • Saya tidak lagi memakai AWS sekarang jadi tidak bisa memverifikasi langsung di konsol, tapi kalau kamu mengalami hal serupa, berikut langkah yang saya sarankan secara garis besar:
    1. Cek akun/subjek yang membuat EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. Lacak aksi lanjutan berdasarkan userIdentity
    3. Cek riwayat login konsol langsung (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Cek riwayat permintaan otentikasi lewat Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. Periksa apakah ada penggunaan AssumeRole melalui sesi STS (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. Cek upaya mempertahankan akses persisten seperti pembuatan IAM Role/Account baru (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. Cek apakah Role/Account yang sudah ada dimodifikasi dengan hak istimewa yang lebih tinggi (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Cek riwayat pembuatan/penghapusan Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. Uji kemungkinan backdoor dari perubahan IAMInstanceProfile pada EC2 produksi (untuk referensi detail, lihat contoh AWS Docs) Jika Anda mencurigai kompromi yang lebih dalam, disarankan untuk melakukan audit dan pemeriksaan lingkungan oleh profesional.
  • Informasinya bagus, jadi saya akan menelusuri log. Berikut beberapa pengamatan tambahan:
    1. Di bawah root account ada 20-an organisasi yang dibuat dan semuanya memakai alamat email dengan domain yang sama (co.jp)
    2. Penyerang membuat beberapa template fargate
    3. Resource dibuat di 16-17 region AWS
    4. Permintaan resource yang tidak perlu terjadi seperti SES, permintaan kenaikan kuota resource AWS Fargate, dan permintaan pemeliharaan notebook SageMaker (saya menerima banyak email notifikasi terkait ini)
    5. Ditemukan adanya nama baru ([e-mail]) ditambahkan pada beberapa email
  • Event RunInstances itulah event yang dimaksud.

• Beberapa pengguna Reddit mengatakan saat gangguan AWS mereka menyegarkan halaman lalu sebentar login sebagai user yang sama sekali berbeda.

  • Di perusahaan tempat saya dulu bekerja juga pernah terjadi kejadian serupa. Beberapa pelanggan sempat mengakses data pelanggan lain. Akar masalahnya ternyata staf internal yang mencoba live debugging di lingkungan produksi secara langsung di waktu itu. (Dulu saya sempat menolak rekrutnya saat wawancara, lol). Masalah ini memang sangat sulit ditelusuri dan diselesaikan.
  • Saya curiga saat gangguan terjadi, DynamoDB sempat inkonsisten sementara sehingga kredensial IAM ikut kacau. Kalau itu benar, betul-betul masalah serius. Ada gak referensi kasus serupa?
  • Kalau ada bukti terkait, mohon dibagikan. Sangat mengejutkan.
  • Saya teringat belakangan apakah ChatGPT juga punya isu serupa. Rasanya mirip.
  • Insiden keamanan seperti ini sangat serius dibandingkan dengan masalah gangguan layanan sementara.

• Dalam kondisi normal, kejadian seperti ini mungkin sekadar kebetulan, tapi umumnya penyebabnya adalah access key yang terekspos. Isu password akun konsol tanpa MFA juga ada, meski lebih jarang.

• Di situasi panik, orang paling rentan terhadap serangan phishing. Wajib reset password secara menyeluruh dan memberi tahu AWS. Biasanya mereka menyelesaikan dengan baik berdasarkan kepercayaan.

• Region us-east-1 ternyata jauh lebih besar dari bayangan. Berdasarkan info publik terbaru, katanya ada 159 data center. Bisa jadi jutaan akun terpusat di sana. Fenomena ini mungkin terkait dengan gangguan AWS, tapi secara pribadi saya pikir peluangnya sebagai kebetulan lebih besar.

  • 159? mengejutkan. Kalau punya sumber yang bisa dirujuk, tolong dibagikan.

• Kelihatan aneh, tapi kalau kamu kasih API key mungkin saya bisa mengecek apakah ada di daftar kebocoran.

  • Saya tahu ini terdengar bercanda, tapi tetap saya ingin menekankan hal penting ini dengan hati-hati. Walaupun bercanda, hindarilah berbagi atau menyebut API key maupun credential. Orang lain bisa menganggap ini serius, jadi berhati-hatilah.