Pada 19 Juli 2019, Capital One menerima pesan yang ditakuti oleh setiap perusahaan modern—telah terjadi pelanggaran data. Penyakit ini berdampak pada lebih dari 106 juta orang. 140 nomor jaminan sosial AS, satu juta nomor jaminan sosial Kanada. 000 rekening bank. Tidak menyenangkan, setujukah Anda?
Sayangnya peretasan tersebut tidak terjadi pada 19 Juli. Ternyata, Paige Thompson, alias. Tak menentu, melakukannya antara 22 Maret dan 23 Maret 2019. Itu adalah hampir empat bulan lalu. Faktanya, hanya dengan bantuan konsultan luar Capital One dapat mengetahui bahwa sesuatu telah terjadi.
Seorang mantan karyawan Amazon ditangkap dan menghadapi denda $250 dan lima tahun penjara... namun masih banyak hal negatif yang tersisa. Mengapa? Karena banyak perusahaan yang terkena dampak peretasan mencoba mengabaikan tanggung jawab untuk memperkuat infrastruktur dan aplikasi mereka di tengah meningkatnya kejahatan dunia maya.
Bagaimanapun, Anda dapat dengan mudah mencari cerita ini di Google. Kami tidak akan membahas drama, tapi membicarakannya teknis sisi masalah.
Pertama-tama, apa yang terjadi?
Capital One menjalankan sekitar 700 bucket S3, yang disalin dan disedot oleh Paige Thompson.
Kedua, apakah ini merupakan kasus lain dari kebijakan bucket S3 yang salah dikonfigurasi?
Tidak, tidak kali ini. Di sini dia memperoleh akses ke server dengan firewall yang tidak dikonfigurasi dengan benar dan melakukan seluruh operasi dari sana.
Tunggu, bagaimana mungkin?
Baiklah, mari kita mulai dengan masuk ke server, meskipun kami tidak memiliki banyak detailnya. Kami hanya diberitahu bahwa hal ini terjadi melalui “firewall yang salah dikonfigurasi”. Jadi, sesuatu yang sederhana seperti pengaturan grup keamanan yang salah atau konfigurasi firewall aplikasi web (Imperva), atau firewall jaringan (iptables, ufw, shorewall, dll.). Capital One hanya mengakui kesalahannya dan mengatakan telah menutup lubangnya.
Stone mengatakan Capital One pada awalnya tidak menyadari kerentanan firewall tetapi bertindak cepat setelah menyadarinya. Hal ini tentu terbantu oleh fakta bahwa peretas diduga meninggalkan informasi pengenal utama di domain publik, kata Stone.
Jika Anda bertanya-tanya mengapa kami tidak membahas lebih dalam bagian ini, harap dipahami bahwa karena terbatasnya informasi, kami hanya dapat berspekulasi. Ini tidak masuk akal mengingat peretasan tersebut bergantung pada lubang yang ditinggalkan oleh Capital One. Dan kecuali mereka memberi tahu kami lebih lanjut, kami hanya akan mencantumkan semua kemungkinan cara Capital One membiarkan server mereka terbuka, dikombinasikan dengan semua kemungkinan cara seseorang dapat menggunakan salah satu opsi berbeda ini. Cacat dan teknik ini bisa berkisar dari kelalaian yang sangat bodoh hingga pola yang sangat rumit. Mengingat banyaknya kemungkinan yang ada, ini akan menjadi kisah panjang tanpa kesimpulan nyata. Oleh karena itu, mari kita fokus menganalisis bagian di mana kita mempunyai fakta.
Jadi kesimpulan pertama adalah: ketahui apa yang diizinkan oleh firewall Anda.
Tetapkan kebijakan atau proses yang tepat untuk memastikan HANYA yang perlu dibuka yang dibuka. Jika Anda menggunakan sumber daya AWS seperti Grup Keamanan atau ACL Jaringan, jelas daftar periksa yang harus diaudit bisa panjang... tetapi seperti banyak sumber daya yang dibuat secara otomatis (yaitu CloudFormation), auditnya juga dapat diotomatisasi. Baik itu skrip buatan sendiri yang memindai objek baru untuk mencari kelemahan, atau sesuatu seperti audit keamanan dalam proses CI/CD... ada banyak opsi mudah untuk menghindari hal ini.
Bagian "lucu" dari cerita ini adalah jika Capital One menutup lubang tersebut sejak awal... tidak akan terjadi apa-apa. Jadi, sejujurnya, selalu mengejutkan melihat sesuatu yang sebenarnya cukup mudah menjadi satu-satunya alasan bagi sebuah perusahaan untuk diretas. Terutama yang sebesar Capital One.
Jadi, peretas di dalam - apa yang terjadi selanjutnya?
Nah, setelah membobol instance EC2... banyak hal yang salah. Anda praktis berjalan di ujung pisau jika membiarkan seseorang bertindak sejauh itu. Namun bagaimana hal itu bisa masuk ke dalam bucket S3? Untuk memahami hal ini, mari kita bahas IAM Roles.
Jadi, salah satu cara untuk mengakses layanan AWS adalah dengan menjadi Pengguna. Oke, yang ini cukup jelas. Namun bagaimana jika Anda ingin memberikan layanan AWS lainnya, seperti server aplikasi Anda, akses ke bucket S3 Anda? Itulah gunanya peran IAM. Mereka terdiri dari dua komponen:
- Kebijakan Kepercayaan - layanan atau orang apa yang dapat menggunakan peran ini?
- Kebijakan Izin - apa yang diperbolehkan oleh peran ini?
Misalnya, Anda ingin membuat IAM role yang memungkinkan instans EC2 mengakses bucket S3: Pertama, peran tersebut diatur agar memiliki Kebijakan Kepercayaan sehingga EC2 (seluruh layanan) atau instans tertentu dapat “mengambil alih” peran tersebut. Menerima peran berarti mereka dapat menggunakan izin peran tersebut untuk melakukan tindakan. Kedua, Kebijakan Izin mengizinkan layanan/orang/sumber daya yang telah “mengambil peran” untuk melakukan apa pun di S3, apakah itu mengakses satu keranjang tertentu... atau lebih dari 700, seperti dalam kasus Capital One.
Setelah Anda berada di instans EC2 dengan peran IAM, Anda dapat memperoleh kredensial dengan beberapa cara:
- Anda dapat meminta metadata instans di
http://169.254.169.254/latest/meta-dataAntara lain, Anda dapat menemukan peran IAM dengan salah satu kunci akses di alamat ini. Tentu saja, hanya jika Anda berada dalam sebuah contoh.
- Gunakan AWS CLI...
Jika AWS CLI diinstal, maka akan dimuat dengan kredensial dari IAM role, jika ada. Yang tersisa hanyalah bekerja MELALUI contoh tersebut. Tentu saja, jika Kebijakan Kepercayaan mereka terbuka, Paige bisa melakukan semuanya secara langsung.
Jadi inti dari peran IAM adalah peran tersebut mengizinkan beberapa sumber daya untuk bertindak ATAS NAMA ANDA terhadap SUMBER DAYA LAIN.
Sekarang setelah Anda memahami peran IAM, kita dapat membicarakan apa yang dilakukan Paige Thompson:
- Dia memperoleh akses ke server (contoh EC2) melalui lubang di firewall
Baik itu grup keamanan/ACL atau firewall aplikasi web mereka sendiri, lubang tersebut mungkin cukup mudah untuk dipasang, sebagaimana dinyatakan dalam catatan resmi.
- Setelah berada di server, dia dapat bertindak “seolah-olah” dia adalah servernya sendiri
- Karena peran server IAM mengizinkan akses S3 ke 700+ bucket ini, maka SXNUMX dapat mengaksesnya
Sejak saat itu, yang harus dia lakukan hanyalah menjalankan perintah List Bucketsdan kemudian perintahnya Sync dari AWS CLI...
. Mencegah kerusakan seperti itu adalah alasan mengapa perusahaan banyak berinvestasi pada perlindungan infrastruktur cloud, DevOps, dan pakar keamanan. Dan seberapa berharga dan hemat biaya peralihan ke cloud? Bahkan ketika menghadapi tantangan keamanan siber yang semakin besar !
Pesan moral dari cerita ini: periksa keselamatan Anda; Melakukan audit rutin; Hormati prinsip hak istimewa paling rendah dalam kebijakan keamanan.
( Anda dapat melihat laporan hukum selengkapnya).
Sumber: www.habr.com