oleh SeerLight
Membina sebarang perkhidmatan semestinya termasuk kerja berterusan mengenai keselamatan. Keselamatan ialah proses berterusan yang merangkumi analisis berterusan dan peningkatan keselamatan produk, memantau berita tentang kelemahan dan banyak lagi. Termasuk audit. Audit dijalankan secara dalaman dan oleh pakar luar, yang secara radikal boleh membantu dengan keselamatan kerana mereka tidak terlibat dalam projek dan mempunyai fikiran terbuka.
Artikel ini adalah mengenai pandangan paling jelas tentang pakar luar yang membantu pasukan Penyelesaian Awan Mail.ru (MCS) menguji perkhidmatan awan dan tentang perkara yang mereka temui. Sebagai "kuasa luar", MCS memilih syarikat Keselamatan Digital, yang terkenal dengan kepakaran tinggi dalam kalangan keselamatan maklumat. Dan dalam artikel ini kami akan menganalisis beberapa kelemahan menarik yang ditemui sebagai sebahagian daripada audit luaran - supaya anda mengelakkan rake yang sama apabila anda membuat perkhidmatan awan anda sendiri.
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ ΠΏΡΠΎΠ΄ΡΠΊΡΠ°
ialah platform untuk membina infrastruktur maya dalam awan. Ia termasuk IaaS, PaaS dan pasaran imej aplikasi siap sedia untuk pembangun. Dengan mengambil kira seni bina MCS, adalah perlu untuk memeriksa keselamatan produk dalam kawasan berikut:
- melindungi infrastruktur persekitaran virtualisasi: hipervisor, penghalaan, tembok api;
- perlindungan infrastruktur maya pelanggan: pengasingan antara satu sama lain, termasuk rangkaian, rangkaian peribadi dalam SDN;
- OpenStack dan komponen terbukanya;
- S3 reka bentuk kami sendiri;
- IAM: projek berbilang penyewa dengan model peranan;
- Visi (penglihatan komputer): API dan kelemahan apabila bekerja dengan imej;
- antara muka web dan serangan web klasik;
- kelemahan komponen PaaS;
- API semua komponen.
Mungkin itu sahaja yang penting untuk sejarah selanjutnya.
Apakah jenis kerja yang telah dijalankan dan mengapa ia diperlukan?
Audit keselamatan bertujuan untuk mengenal pasti kelemahan dan ralat konfigurasi yang boleh menyebabkan kebocoran data peribadi, pengubahsuaian maklumat sensitif atau gangguan ketersediaan perkhidmatan.
Semasa kerja, yang berlangsung secara purata 1-2 bulan, juruaudit mengulangi tindakan penyerang yang berpotensi dan mencari kelemahan pada bahagian klien dan pelayan perkhidmatan yang dipilih. Dalam konteks audit platform awan MCS, matlamat berikut telah dikenal pasti:
- Analisis pengesahan dalam perkhidmatan. Kerentanan dalam komponen ini akan membantu untuk segera masuk ke akaun orang lain.
- Mempelajari model peranan dan kawalan akses antara akaun yang berbeza. Bagi penyerang, keupayaan untuk mendapatkan akses kepada mesin maya orang lain adalah matlamat yang diingini.
- Kelemahan pihak pelanggan. XSS/CSRF/CRLF/dsb. Adakah mungkin untuk menyerang pengguna lain melalui pautan berniat jahat?
- Kelemahan sisi pelayan: RCE dan semua jenis suntikan (SQL/XXE/SSRF dan sebagainya). Kerentanan pelayan biasanya lebih sukar dicari, tetapi ia membawa kepada kompromi ramai pengguna sekaligus.
- Analisis pengasingan segmen pengguna di peringkat rangkaian. Bagi penyerang, kekurangan pengasingan sangat meningkatkan permukaan serangan terhadap pengguna lain.
- Analisis logik perniagaan. Adakah mungkin untuk menipu perniagaan dan mencipta mesin maya secara percuma?
Dalam projek ini, kerja telah dijalankan mengikut model "Kotak Kelabu": juruaudit berinteraksi dengan perkhidmatan dengan keistimewaan pengguna biasa, tetapi sebahagiannya memiliki kod sumber API dan mempunyai peluang untuk menjelaskan butiran dengan pembangun. Ini biasanya model kerja yang paling mudah, dan pada masa yang sama agak realistik: maklumat dalaman masih boleh dikumpul oleh penyerang, hanya menunggu masa.
Kerentanan ditemui
Sebelum juruaudit mula menghantar pelbagai muatan (muatan yang digunakan untuk menjalankan serangan) ke tempat rawak, adalah perlu untuk memahami cara kerja dan fungsi yang disediakan. Nampaknya ini adalah latihan yang tidak berguna, kerana di kebanyakan tempat yang dikaji tidak akan ada kelemahan. Tetapi hanya memahami struktur aplikasi dan logik operasinya akan memungkinkan untuk mencari vektor serangan yang paling kompleks.
Adalah penting untuk mencari tempat yang kelihatan mencurigakan atau sangat berbeza daripada yang lain dalam beberapa cara. Dan kelemahan berbahaya pertama ditemui dengan cara ini.
IDOR
Kerentanan IDOR (Rujukan Objek Langsung Tidak Selamat) ialah salah satu kelemahan yang paling biasa dalam logik perniagaan, yang membolehkan seseorang atau yang lain mendapat akses kepada objek yang aksesnya sebenarnya tidak dibenarkan. Kerentanan IDOR mewujudkan kemungkinan mendapatkan maklumat tentang pengguna yang mempunyai tahap kritikal yang berbeza-beza.
Salah satu pilihan IDOR ialah melakukan tindakan dengan objek sistem (pengguna, akaun bank, item dalam troli beli-belah) dengan memanipulasi pengecam akses kepada objek ini. Ini membawa kepada akibat yang paling tidak dapat diramalkan. Sebagai contoh, kemungkinan menggantikan akaun pengirim dana, di mana anda boleh mencurinya daripada pengguna lain.
Dalam kes MCS, juruaudit baru sahaja menemui kelemahan IDOR yang dikaitkan dengan pengecam tidak selamat. Dalam akaun peribadi pengguna, pengecam UUID digunakan untuk mengakses sebarang objek, yang nampaknya, seperti yang dikatakan pakar keselamatan, sangat tidak selamat (iaitu, dilindungi daripada serangan kekerasan). Tetapi untuk entiti tertentu, didapati bahawa nombor boleh diramal biasa digunakan untuk mendapatkan maklumat tentang pengguna aplikasi. Saya fikir anda boleh meneka bahawa adalah mungkin untuk menukar ID pengguna dengan satu, menghantar permintaan sekali lagi dan dengan itu mendapatkan maklumat yang memintas ACL (senarai kawalan akses, peraturan akses data untuk proses dan pengguna).
Pemalsuan Permintaan Sisi Pelayan (SSRF)
Perkara yang baik tentang produk OpenSource ialah mereka mempunyai sejumlah besar forum dengan penerangan teknikal terperinci tentang masalah yang timbul dan, jika anda bernasib baik, penerangan mengenai penyelesaiannya. Tetapi syiling ini mempunyai sisi lain: kelemahan yang diketahui juga diterangkan secara terperinci. Sebagai contoh, terdapat huraian indah tentang kelemahan pada forum OpenStack ΠΈ , yang atas sebab tertentu tiada siapa yang tergesa-gesa untuk membetulkannya.
Kefungsian umum aplikasi ialah keupayaan untuk pengguna menghantar pautan ke pelayan, yang pelayan klik pada (contohnya, untuk memuat turun imej daripada sumber yang ditentukan). Jika alat keselamatan tidak menapis pautan itu sendiri atau respons yang dikembalikan daripada pelayan kepada pengguna, fungsi tersebut boleh digunakan dengan mudah oleh penyerang.
Kerentanan SSRF boleh memajukan perkembangan serangan. Penyerang boleh mendapatkan:
- akses terhad kepada rangkaian tempatan yang diserang, contohnya, hanya melalui segmen rangkaian tertentu dan menggunakan protokol tertentu;
- akses penuh kepada rangkaian tempatan, jika penurunan taraf dari peringkat aplikasi ke tahap pengangkutan adalah mungkin dan, sebagai hasilnya, pengurusan beban penuh di peringkat aplikasi;
- akses untuk membaca fail tempatan pada pelayan (jika skema fail:/// disokong);
- dan banyak lagi.
Kerentanan SSRF telah lama diketahui dalam OpenStack, yang bersifat "buta": apabila anda menghubungi pelayan, anda tidak menerima respons daripadanya, tetapi anda menerima pelbagai jenis ralat/penangguhan, bergantung pada hasil permintaan . Berdasarkan ini, anda boleh melakukan imbasan port pada hos pada rangkaian dalaman, dengan semua akibat berikutnya yang tidak boleh dipandang remeh. Sebagai contoh, produk mungkin mempunyai API pejabat belakang yang hanya boleh diakses daripada rangkaian korporat. Dengan dokumentasi (jangan lupa tentang orang dalam), penyerang boleh menggunakan SSRF untuk mengakses kaedah dalaman. Sebagai contoh, jika anda entah bagaimana boleh mendapatkan senarai anggaran URL yang berguna, maka menggunakan SSRF anda boleh melaluinya dan melaksanakan permintaan - secara relatifnya, pindahkan wang dari akaun ke akaun atau menukar had.
Ini bukan kali pertama kerentanan SSRF ditemui dalam OpenStack. Pada masa lalu, adalah mungkin untuk memuat turun imej ISO VM dari pautan terus, yang juga membawa kepada akibat yang serupa. Ciri ini kini telah dialih keluar daripada OpenStack. Nampaknya, masyarakat menganggap ini penyelesaian yang paling mudah dan boleh dipercayai untuk masalah itu.
Dan dalam laporan tersedia secara umum daripada perkhidmatan HackerOne (h1), eksploitasi SSRF yang tidak buta lagi dengan keupayaan membaca metadata contoh membawa kepada akses Root kepada keseluruhan infrastruktur Shopify.
Dalam MCS, kerentanan SSRF ditemui di dua tempat dengan fungsi yang sama, tetapi hampir mustahil untuk dieksploitasi disebabkan oleh tembok api dan perlindungan lain. Walau bagaimanapun, pasukan MCS menyelesaikan masalah ini, tanpa menunggu komuniti.
XSS bukannya memuatkan cengkerang
Walaupun beratus-ratus kajian ditulis, tahun demi tahun serangan XSS (cross-site scripting) masih menjadi yang paling banyak kelemahan web (atau ?).
Muat naik fail ialah tempat kegemaran bagi mana-mana penyelidik keselamatan. Selalunya ternyata anda boleh memuatkan skrip sewenang-wenangnya (asp/jsp/php) dan melaksanakan perintah OS, dalam terminologi pentesters - "load shell". Tetapi populariti kelemahan sedemikian berfungsi dalam kedua-dua arah: ia diingati dan remedi dibangunkan terhadapnya, sehingga baru-baru ini kebarangkalian "memuatkan cangkang" cenderung kepada sifar.
Pasukan penyerang (diwakili oleh Digital Security) bertuah. OK, dalam MCS pada bahagian pelayan kandungan fail yang dimuat turun telah disemak, hanya imej dibenarkan. Tetapi SVG juga adalah gambar. Bagaimanakah imej SVG boleh berbahaya? Kerana anda boleh membenamkan coretan JavaScript ke dalamnya!
Ternyata fail yang dimuat turun tersedia untuk semua pengguna perkhidmatan MCS, yang bermaksud bahawa adalah mungkin untuk menyerang pengguna awan lain, iaitu pentadbir.
Contoh serangan XSS pada borang log masuk pancingan data
Contoh eksploitasi serangan XSS:
- Mengapa cuba mencuri sesi (terutamanya kerana kini kuki HTTP-Only ada di mana-mana, dilindungi daripada kecurian menggunakan skrip js), jika skrip yang dimuatkan boleh mengakses API sumber dengan segera? Dalam kes ini, muatan boleh menggunakan permintaan XHR untuk menukar konfigurasi pelayan, contohnya, menambah kunci SSH awam penyerang dan mendapatkan akses SSH ke pelayan.
- Jika dasar CSP (dasar perlindungan kandungan) melarang JavaScript daripada disuntik, penyerang boleh bertahan tanpanya. Menggunakan HTML tulen, cipta borang log masuk palsu untuk tapak dan curi kata laluan pentadbir melalui pancingan data lanjutan ini: halaman pancingan data untuk pengguna berakhir di URL yang sama, dan lebih sukar bagi pengguna untuk mengesannya.
- Akhirnya, penyerang boleh mengatur β tetapkan Kuki lebih besar daripada 4 KB. Pengguna hanya perlu membuka pautan sekali, dan keseluruhan tapak menjadi tidak boleh diakses sehingga pengguna berfikir untuk membersihkan penyemak imbas secara khusus: dalam kebanyakan kes, pelayan web akan enggan menerima pelanggan sedemikian.
Mari lihat contoh XSS lain yang dikesan, kali ini dengan eksploitasi yang lebih bijak. Perkhidmatan MCS membolehkan anda menggabungkan tetapan tembok api ke dalam kumpulan. Nama kumpulan adalah tempat XSS dikesan. Keanehannya ialah vektor tidak dicetuskan serta-merta, bukan semasa melihat senarai peraturan, tetapi apabila memadamkan kumpulan:
Iaitu, senario itu ternyata seperti berikut: penyerang mencipta peraturan tembok api dengan "beban" dalam nama, pentadbir melihatnya selepas beberapa ketika dan memulakan proses pemadaman. Dan di sinilah JS berniat jahat berfungsi.
Untuk pembangun MCS, untuk melindungi daripada XSS dalam imej SVG yang dimuat turun (jika ia tidak boleh ditinggalkan), pasukan Keselamatan Digital mengesyorkan:
- Letakkan fail yang dimuat naik oleh pengguna pada domain berasingan yang tiada kaitan dengan "kuki". Skrip akan dilaksanakan dalam konteks domain yang berbeza dan tidak akan menimbulkan ancaman kepada MCS.
- Dalam respons HTTP pelayan, hantar pengepala "Pelupusan kandungan: lampiran". Kemudian fail akan dimuat turun oleh pelayar dan tidak dilaksanakan.
Selain itu, kini terdapat banyak cara yang tersedia untuk pembangun untuk mengurangkan risiko eksploitasi XSS:
- menggunakan bendera "HTTP Sahaja", anda boleh menjadikan pengepala "Kuki" sesi tidak boleh diakses oleh JavaScript yang berniat jahat;
- akan menjadikannya lebih sukar bagi penyerang untuk mengeksploitasi XSS;
- enjin templat moden seperti Angular atau React membersihkan data pengguna secara automatik sebelum mengeluarkannya ke penyemak imbas pengguna.
Kelemahan pengesahan dua faktor
Untuk meningkatkan keselamatan akaun, pengguna sentiasa dinasihatkan untuk mendayakan 2FA (pengesahan dua faktor). Sesungguhnya, ini adalah cara yang berkesan untuk menghalang penyerang daripada mendapat akses kepada perkhidmatan jika kelayakan pengguna telah terjejas.
Tetapi adakah menggunakan faktor pengesahan kedua sentiasa menjamin keselamatan akaun? Terdapat isu keselamatan berikut dalam pelaksanaan 2FA:
- Carian kasar kod OTP (kod satu kali). Walaupun kesederhanaan operasi, ralat seperti kekurangan perlindungan terhadap kekerasan OTP juga dihadapi oleh syarikat besar: , .
- Algoritma penjanaan yang lemah, contohnya keupayaan untuk meramalkan kod seterusnya.
- Ralat logik, seperti keupayaan untuk meminta OTP orang lain pada telefon anda, seperti ini daripada Shopify.
Dalam kes MCS, 2FA dilaksanakan berdasarkan Google Authenticator dan . Protokol itu sendiri telah diuji masa, tetapi pelaksanaan pengesahan kod pada bahagian aplikasi patut diperiksa.
MCS 2FA digunakan di beberapa tempat:
- Apabila mengesahkan pengguna. Terdapat perlindungan terhadap kekerasan: pengguna hanya mempunyai beberapa percubaan untuk memasukkan kata laluan sekali, kemudian input disekat untuk seketika. Ini menyekat kemungkinan pemilihan kekerasan OTP.
- Apabila menjana kod sandaran luar talian untuk melaksanakan 2FA, serta melumpuhkannya. Di sini, tiada perlindungan kekerasan telah dilaksanakan, yang memungkinkan, jika anda mempunyai kata laluan untuk akaun dan sesi aktif, untuk menjana semula kod sandaran atau melumpuhkan 2FA sepenuhnya.
Memandangkan kod sandaran terletak dalam julat nilai rentetan yang sama seperti yang dijana oleh aplikasi OTP, peluang untuk mencari kod dalam masa yang singkat adalah lebih tinggi.
Proses memilih OTP untuk melumpuhkan 2FA menggunakan alat "Burp: Intruder".
Keputusan
Secara keseluruhan, MCS nampaknya selamat sebagai produk. Semasa audit, pasukan pentesting tidak dapat memperoleh akses kepada VM pelanggan dan data mereka, dan kelemahan yang ditemui telah diperbetulkan dengan cepat oleh pasukan MCS.
Tetapi di sini adalah penting untuk diperhatikan bahawa keselamatan adalah kerja yang berterusan. Perkhidmatan tidak statik, ia sentiasa berkembang. Dan adalah mustahil untuk membangunkan produk sepenuhnya tanpa kelemahan. Tetapi anda boleh menemuinya tepat pada masanya dan meminimumkan kemungkinan berulangnya.
Kini semua kelemahan yang disebutkan dalam MCS telah pun diperbaiki. Dan untuk mengekalkan bilangan yang baharu pada tahap minimum dan mengurangkan hayat mereka, pasukan platform terus melakukan perkara ini:
- kerap menjalankan audit oleh syarikat luar;
- menyokong dan membangunkan penyertaan;
- melibatkan diri dalam keselamatan. π
Sumber: www.habr.com