Pada 19 Julai 2019, Capital One menerima mesej yang ditakuti oleh setiap syarikat moden—pelanggaran data berlaku. Ia menjejaskan lebih daripada 106 juta orang. 140 nombor keselamatan sosial AS, satu juta nombor keselamatan sosial Kanada. 000 akaun bank. Tidak menyenangkan, adakah anda tidak bersetuju?
Malangnya, penggodaman itu tidak berlaku pada 19 Julai. Ternyata, Paige Thompson, a.k.a. Tidak menentu, melaksanakannya antara 22 Mac dan 23 Mac 2019. Itu dia hampir empat bulan yang lalu. Malah, hanya dengan bantuan perunding luar yang Capital One dapat mengetahui bahawa sesuatu telah berlaku.
Seorang bekas pekerja Amazon telah ditangkap dan berdepan denda $250 dan penjara lima tahun... tetapi masih terdapat banyak perkara negatif yang tinggal. kenapa? Kerana banyak syarikat yang mengalami penggodaman cuba mengenepikan tanggungjawab untuk mengukuhkan infrastruktur dan aplikasi mereka di tengah-tengah peningkatan jenayah siber.
Apa pun, anda boleh google dengan mudah cerita ini. Kami tidak akan masuk ke dalam drama, tetapi bercakap tentang teknikal sisi perkara itu.
Pertama sekali, apa yang berlaku?
Capital One mempunyai kira-kira 700 baldi S3 berjalan, yang disalin dan disedut oleh Paige Thompson.
Kedua, adakah ini satu lagi kes dasar baldi S3 yang salah konfigurasi?
Tidak, bukan kali ini. Di sini dia mendapat akses kepada pelayan dengan tembok api yang dikonfigurasikan secara salah dan menjalankan keseluruhan operasi dari sana.
Tunggu, bagaimana mungkin?
Baiklah, mari kita mulakan dengan log masuk ke pelayan, walaupun kita tidak mempunyai banyak butiran. Kami hanya diberitahu bahawa ia berlaku melalui "firewall yang salah konfigurasi." Jadi, sesuatu yang mudah seperti tetapan kumpulan keselamatan yang salah atau konfigurasi tembok api aplikasi web (Imperva), atau tembok api rangkaian (iptables, ufw, shorewall, dll.). Capital One hanya mengakui kesalahannya dan berkata ia telah menutup lubang itu.
Stone berkata Capital One pada mulanya tidak menyedari kerentanan firewall tetapi bertindak pantas sebaik sahaja ia menyedarinya. Ini pastinya dibantu oleh fakta bahawa penggodam didakwa meninggalkan maklumat pengenalpastian utama dalam domain awam, kata Stone.
Jika anda tertanya-tanya mengapa kami tidak mendalami bahagian ini, sila faham bahawa disebabkan maklumat yang terhad, kami hanya boleh membuat spekulasi. Ini tidak masuk akal memandangkan penggodaman itu bergantung pada lubang yang ditinggalkan oleh Capital One. Dan melainkan mereka memberitahu kami lebih lanjut, kami hanya akan menyenaraikan semua cara yang mungkin Capital One membiarkan pelayan mereka terbuka dalam kombinasi dengan semua cara yang mungkin seseorang boleh menggunakan salah satu daripada pilihan yang berbeza ini. Kelemahan dan teknik ini boleh terdiri daripada kesilapan yang sangat bodoh kepada corak yang sangat kompleks. Memandangkan pelbagai kemungkinan, ini akan menjadi kisah yang panjang tanpa kesimpulan sebenar. Oleh itu, mari kita fokus pada menganalisis bahagian di mana kita mempunyai fakta.
Jadi perkara pertama yang boleh diambil ialah: ketahui perkara yang dibenarkan oleh tembok api anda.
Wujudkan polisi atau proses yang betul untuk memastikan HANYA perkara yang perlu dibuka dibuka. Jika anda menggunakan sumber AWS seperti Kumpulan Keselamatan atau ACL Rangkaian, jelas sekali senarai semak untuk diaudit boleh panjang... tetapi sama seperti banyak sumber dicipta secara automatik (iaitu CloudFormation), anda juga boleh mengautomasikan pengauditan mereka. Sama ada skrip buatan sendiri yang mengimbas objek baharu untuk mengesan kecacatan, atau sesuatu seperti audit keselamatan dalam proses CI/CD... terdapat banyak pilihan mudah untuk mengelakkan perkara ini.
Bahagian yang "lucu" dalam cerita ini ialah jika Capital One telah menyumbat lubang itu di tempat pertama... tiada apa yang akan berlaku. Jadi, terus terang, ia sentiasa mengejutkan untuk melihat bagaimana sesuatu itu sebenarnya cukup mudah menjadi satu-satunya sebab syarikat digodam. Terutamanya yang sebesar Capital One.
Jadi, penggodam di dalam - apa yang berlaku seterusnya?
Nah, selepas menceroboh contoh EC2... banyak yang boleh berlaku. Anda boleh berjalan di atas mata pisau jika anda membiarkan seseorang pergi sejauh itu. Tetapi bagaimana ia masuk ke dalam baldi S3? Untuk memahami perkara ini, mari kita bincangkan Peranan IAM.
Jadi, satu cara untuk mengakses perkhidmatan AWS ialah menjadi Pengguna. Okay, yang ini agak jelas. Tetapi bagaimana jika anda ingin memberikan perkhidmatan AWS lain, seperti pelayan aplikasi anda, akses kepada baldi S3 anda? Itulah gunanya peranan IAM. Mereka terdiri daripada dua komponen:
- Dasar Amanah - apakah perkhidmatan atau orang yang boleh menggunakan peranan ini?
- Dasar Kebenaran - apakah yang dibenarkan oleh peranan ini?
Sebagai contoh, anda ingin mencipta peranan IAM yang akan membenarkan tika EC2 mengakses baldi S3: Pertama, peranan ditetapkan untuk mempunyai Dasar Amanah yang EC2 (keseluruhan perkhidmatan) atau tika tertentu boleh "mengambil alih" peranan tersebut. Menerima peranan bermakna mereka boleh menggunakan kebenaran peranan untuk melaksanakan tindakan. Kedua, Dasar Kebenaran membenarkan perkhidmatan/orang/sumber yang telah "mengambil peranan" untuk melakukan apa sahaja di S3, sama ada mengakses satu baldi tertentu... atau lebih 700, seperti dalam kes Capital One.
Sebaik sahaja anda berada dalam contoh EC2 dengan peranan IAM, anda boleh mendapatkan kelayakan dalam beberapa cara:
- Anda boleh meminta metadata contoh di
http://169.254.169.254/latest/meta-dataAntara lain, anda boleh mencari peranan IAM dengan mana-mana kunci akses di alamat ini. Sudah tentu, hanya jika anda berada dalam contoh.
- Gunakan AWS CLI...
Jika AWS CLI dipasang, ia dimuatkan dengan bukti kelayakan daripada peranan IAM, jika ada. Yang tinggal hanyalah bekerja MELALUI contoh. Sudah tentu, jika Dasar Amanah mereka terbuka, Paige boleh melakukan segala-galanya secara langsung.
Jadi intipati peranan IAM ialah mereka membenarkan beberapa sumber bertindak BAGI PIHAK ANDA ke atas SUMBER LAIN.
Kini setelah anda memahami peranan IAM, kita boleh bercakap tentang perkara yang Paige Thompson lakukan:
- Dia mendapat akses kepada pelayan (contoh EC2) melalui lubang di dinding api
Sama ada kumpulan keselamatan/ACL atau tembok api aplikasi web mereka sendiri, lubang itu mungkin agak mudah dipalam, seperti yang dinyatakan dalam rekod rasmi.
- Setelah berada di pelayan, dia dapat bertindak "seolah-olah" dia adalah pelayan itu sendiri
- Memandangkan peranan pelayan IAM membenarkan akses S3 kepada 700+ baldi ini, ia dapat mengaksesnya
Mulai saat itu, apa yang dia perlu lakukan hanyalah menjalankan arahan List Bucketsdan kemudian perintah Sync daripada AWS CLI...
. Mencegah kerosakan sedemikian adalah sebab syarikat melabur banyak dalam perlindungan infrastruktur awan, DevOps dan pakar keselamatan. Dan sejauh manakah nilai dan kos efektif yang dipindahkan ke awan? Sehinggakan walaupun menghadapi cabaran keselamatan siber yang semakin banyak !
Moral of the story: semak keselamatan anda; Menjalankan audit secara berkala; Hormati prinsip keistimewaan yang paling sedikit untuk dasar keselamatan.
( Anda boleh melihat laporan undang-undang penuh).
Sumber: www.habr.com