dening SeerLight
Mbangun layanan apa wae kudu kalebu kerja terus-terusan babagan keamanan. Keamanan minangka proses terus-terusan sing kalebu analisis terus-terusan lan perbaikan keamanan produk, ngawasi kabar babagan kerentanan lan liya-liyane. Kalebu audit. Audit dileksanakake ing omah lan dening ahli eksternal, sing bisa mbantu keamanan kanthi radikal amarga ora kecemplung ing proyek kasebut lan duwe pikiran sing mbukak.
Artikel kasebut babagan tampilan paling langsung saka pakar eksternal sing mbantu tim Mail.ru Cloud Solutions (MCS) nguji layanan awan, lan babagan apa sing ditemokake. Minangka "pasukan eksternal," MCS milih perusahaan Keamanan Digital, sing dikenal kanthi keahlian dhuwur ing kalangan keamanan informasi. Lan ing artikel iki, kita bakal nganalisa sawetara kerentanan menarik sing ditemokake minangka bagean saka audit eksternal - supaya sampeyan ngindhari rake sing padha nalika nggawe layanan maya dhewe.
Описание продукта
minangka platform kanggo mbangun infrastruktur virtual ing méga. Iku kalebu IaaS, PaaS, lan pasar gambar aplikasi siap kanggo pangembang. Nganggep arsitektur MCS, perlu kanggo mriksa safety produk ing wilayah ing ngisor iki:
- nglindhungi infrastruktur lingkungan virtualisasi: hypervisor, routing, firewall;
- pangayoman infrastruktur virtual pelanggan: isolasi saka saben liyane, kalebu jaringan, jaringan pribadi ing SDN;
- OpenStack lan komponen mbukak;
- S3 saka desain kita dhewe;
- IAM: proyek multi-tenant kanthi panutan;
- Visi (visi komputer): API lan kerentanan nalika nggarap gambar;
- antarmuka web lan serangan web klasik;
- kerentanan komponen PaaS;
- API kabeh komponen.
Mungkin iku kabeh sing penting kanggo sejarah luwih lanjut.
Apa jenis karya sing ditindakake lan kenapa perlu?
Audit keamanan ditujokake kanggo ngenali kerentanan lan kesalahan konfigurasi sing bisa nyebabake kebocoran data pribadhi, modifikasi informasi sensitif, utawa gangguan kasedhiyan layanan.
Sajrone karya, sing rata-rata 1-2 sasi, auditor mbaleni tumindak panyerang potensial lan nggoleki kerentanan ing bagean klien lan server saka layanan sing dipilih. Ing konteks audit platform awan MCS, tujuan ing ngisor iki diidentifikasi:
- Analisis otentikasi ing layanan. Kerentanan ing komponen iki bakal mbantu langsung mlebu ing akun wong liya.
- Sinau model peran lan kontrol akses antarane akun beda. Kanggo penyerang, kemampuan kanggo entuk akses menyang mesin virtual wong liya minangka tujuan sing dikarepake.
- Kerentanan sisih klien. XSS / CSRF / CRLF / lsp. Apa bisa nyerang pangguna liya liwat pranala ala?
- Kerentanan sisih server: RCE lan kabeh jinis injeksi (SQL/XXE/SSRF lan sapiturute). Kerentanan server umume luwih angel ditemokake, nanging nyebabake kompromi akeh pangguna sekaligus.
- Analisis isolasi segmen pangguna ing tingkat jaringan. Kanggo penyerang, kekurangan pengasingan nambah permukaan serangan marang pangguna liyane.
- Analisis logika bisnis. Apa bisa ngapusi bisnis lan nggawe mesin virtual gratis?
Ing proyek iki, karya ditindakake miturut model "Gray-box": auditor berinteraksi karo layanan kasebut kanthi hak istimewa pangguna biasa, nanging sebagian duwe kode sumber API lan duwe kesempatan kanggo njlentrehake rincian karo pangembang. Iki biasane sing paling trep, lan ing wektu sing padha model karya sing cukup nyata: informasi internal isih bisa diklumpukake dening panyerang, mung sawetara wektu.
Kerentanan ditemokake
Sadurunge auditor wiwit ngirim macem-macem payloads (payload digunakake kanggo nindakake serangan) kanggo panggonan acak, iku perlu kanggo ngerti carane iku bisa lan apa fungsi kasedhiya. Koyone iki minangka latihan sing ora ana gunane, amarga ing sebagian besar papan sing diteliti ora bakal ana kerentanan. Nanging mung ngerti struktur aplikasi lan logika operasi bakal bisa nemokake vektor serangan sing paling rumit.
Penting kanggo nemokake panggonan sing katon curiga utawa beda banget karo wong liya ing sawetara cara. Lan kerentanan mbebayani pisanan ditemokake kanthi cara iki.
IDOR
IDOR (Insecure Direct Object Reference) kerentanan minangka salah sawijining kerentanan sing paling umum ing logika bisnis, sing ngidini siji utawa liyane entuk akses menyang obyek sing ora diidini akses. Kerentanan IDOR nggawe kemungkinan entuk informasi babagan pangguna kanthi tingkat kritisitas sing beda-beda.
Salah sawijining opsi IDOR yaiku nindakake tumindak karo obyek sistem (pangguna, akun bank, barang ing keranjang belanja) kanthi manipulasi pengenal akses menyang obyek kasebut. Iki nyebabake akibat sing paling ora bisa ditebak. Contone, kemungkinan ngganti akun pangirim dana, sing bisa dicolong saka pangguna liyane.
Ing kasus MCS, auditor mung nemokake kerentanan IDOR sing ana gandhengane karo pengenal sing ora aman. Ing akun pribadhi pangguna, pengenal UUID digunakake kanggo ngakses obyek apa wae, sing katon, kaya sing dikandhakake para ahli keamanan, pancen ora aman (yaiku, dilindhungi saka serangan brute force). Nanging kanggo entitas tartamtu, ditemokake yen angka sing bisa diprediksi biasa digunakake kanggo entuk informasi babagan pangguna aplikasi kasebut. Aku sampeyan bisa guess sing iku bisa kanggo ngganti ID panganggo siji, ngirim panjalukan maneh lan kanthi mangkono njupuk informasi bypassing ACL (dhaftar kontrol akses, aturan akses data kanggo pangolahan lan pangguna).
Server Side Request Forgery (SSRF)
Sing apik babagan produk OpenSource yaiku duwe akeh forum kanthi katrangan teknis rinci babagan masalah sing muncul lan, yen sampeyan duwe bathi, katrangan babagan solusi kasebut. Nanging duwit receh iki duwe sisih loncat karo muter awak: vulnerabilities dikenal uga diterangake ing rinci. Contone, ana deskripsi kerentanan sing apik ing forum OpenStack и , sing sakperangan alesan ora ana sing kesusu kanggo ndandani.
Fungsi umum aplikasi yaiku kemampuan kanggo pangguna ngirim link menyang server, sing diklik server (contone, kanggo ngundhuh gambar saka sumber sing ditemtokake). Yen alat keamanan ora nyaring pranala dhewe utawa respon bali saka server kanggo pangguna, fungsi kuwi bisa gampang digunakake dening panyerang.
Kerentanan SSRF bisa ningkatake pangembangan serangan. Penyerang bisa entuk:
- akses winates menyang jaringan lokal sing diserang, contone, mung liwat segmen jaringan tartamtu lan nggunakake protokol tartamtu;
- akses lengkap menyang jaringan lokal, yen downgrade saka tingkat aplikasi kanggo tingkat transportasi bisa lan, minangka asil, Manajemen mbukak lengkap ing tingkat aplikasi;
- akses kanggo maca file lokal ing server (yen file: /// skema didhukung);
- lan luwih akeh.
Kerentanan SSRF wis suwe dikenal ing OpenStack, sing sifate "buta": nalika sampeyan ngubungi server, sampeyan ora nampa respon, nanging sampeyan nampa macem-macem kesalahan / telat, gumantung saka asil panyuwunan. . Adhedhasar iki, sampeyan bisa nindakake scan port ing sarwa dumadi ing jaringan internal, karo kabeh jalaran sabanjuré sing ngirim ora disepelekake. Contone, produk bisa uga duwe API kantor mburi sing mung bisa diakses saka jaringan perusahaan. Kanthi dokumentasi (aja lali babagan wong njero), penyerang bisa nggunakake SSRF kanggo ngakses metode internal. Contone, yen sampeyan bisa entuk dhaptar kira-kira URL sing migunani, banjur nggunakake SSRF sampeyan bisa ngliwati lan nglakokake panjaluk - kanthi relatif, transfer dhuwit saka akun menyang akun utawa ngganti watesan.
Iki dudu pisanan kerentanan SSRF ditemokake ing OpenStack. Ing jaman biyen, bisa ndownload gambar VM ISO saka tautan langsung, sing uga nyebabake akibat sing padha. Fitur iki saiki wis dibusak saka OpenStack. Ketoke, masyarakat nganggep iki minangka solusi sing paling gampang lan paling dipercaya kanggo masalah kasebut.
Lan ing laporan sing kasedhiya kanggo umum saka layanan HackerOne (h1), eksploitasi SSRF sing ora wuta maneh kanthi kemampuan maca metadata conto ndadékaké akses Root menyang kabeh infrastruktur Shopify.
Ing MCS, kerentanan SSRF ditemokake ing rong panggonan kanthi fungsi sing padha, nanging meh ora bisa dimanfaatake amarga firewall lan proteksi liyane. Siji cara utawa liyane, tim MCS ngatasi masalah iki, tanpa ngenteni komunitas.
XSS tinimbang mbukak cangkang
Sanajan atusan studi ditulis, serangan XSS (cross-site scripting) tetep paling akeh kerentanan web (utawa ?).
Unggahan file minangka panggonan favorit kanggo peneliti keamanan. Asring ternyata sampeyan bisa mbukak skrip sewenang-wenang (asp/jsp/php) lan nglakokake perintah OS, ing terminologi pentesters - "load shell". Nanging popularitas kerentanan kasebut bisa digunakake ing loro arah: wong ngelingi babagan kasebut lan ngembangake obat-obatan marang wong-wong mau, saengga bubar kemungkinan "munggah cangkang" cenderung nol.
Tim penyerang (diwakili dening Keamanan Digital) begja. OK, ing MCS ing sisih server, isi file sing diundhuh dicenthang, mung gambar sing diidini. Nanging SVG uga gambar. Kepiye carane gambar SVG bisa mbebayani? Amarga sampeyan bisa nglebokake potongan JavaScript menyang dheweke!
Ternyata file sing diunduh kasedhiya kanggo kabeh pangguna layanan MCS, tegese bisa nyerang pangguna awan liyane, yaiku administrator.
Conto serangan XSS ing formulir login phishing
Conto eksploitasi serangan XSS:
- Napa nyoba nyolong sesi (utamane amarga saiki cookie HTTP-Mung ana ing endi wae, dilindhungi saka nyolong nggunakake skrip js), yen skrip sing dimuat bisa langsung ngakses API sumber? Ing kasus iki, muatan bisa nggunakake panjalukan XHR kanggo ngganti konfigurasi server, contone, nambah kunci SSH umum penyerang lan entuk akses SSH menyang server.
- Yen kabijakan CSP (kabijakan perlindungan konten) nglarang JavaScript disuntikake, panyerang bisa lolos tanpa ana. Nggunakake HTML murni, nggawe formulir login palsu kanggo situs kasebut lan nyolong sandhi administrator liwat phishing canggih iki: kaca phishing kanggo pangguna rampung ing URL sing padha, lan luwih angel kanggo pangguna ndeteksi.
- Pungkasan, panyerang bisa ngatur - nyetel Cookie luwih gedhe tinimbang 4 KB. Pangguna mung kudu mbukak link sapisan, lan kabeh situs dadi ora bisa diakses nganti pangguna mikir kanggo ngresiki browser khusus: ing mayoritas kasus, server web bakal nolak nampa klien kasebut.
Ayo goleki conto XSS liyane sing dideteksi, wektu iki kanthi eksploitasi sing luwih pinter. Layanan MCS ngidini sampeyan nggabungake setelan firewall menyang grup. Jeneng grup ing ngendi XSS dideteksi. Keanehane yaiku vektor ora langsung dipicu, ora nalika ndeleng dhaptar aturan, nanging nalika mbusak grup:
Yaiku, skenario kasebut kaya ing ngisor iki: panyerang nggawe aturan firewall kanthi jeneng "muat", administrator ngelingi sawise sawetara wektu lan miwiti proses pambusakan. Lan ing kene JS angkoro bisa digunakake.
Kanggo pangembang MCS nglindhungi saka XSS ing gambar SVG sing diunggah (yen ora bisa diilangi), tim Keamanan Digital nyaranake:
- Selehake file sing diunggah dening pangguna ing domain kapisah sing ora ana hubungane karo "cookie". Skrip bakal dieksekusi ing konteks domain sing beda lan ora bakal dadi ancaman kanggo MCS.
- Ing respon HTTP server, kirim header "Content-disposition: attachment". Banjur file bakal diundhuh dening browser lan ora dieksekusi.
Kajaba iku, saiki ana akeh cara sing kasedhiya kanggo pangembang kanggo nyuda risiko eksploitasi XSS:
- nggunakake gendera "Mung HTTP", sampeyan bisa nggawe header sesi "Cookies" ora bisa diakses dening JavaScript angkoro;
- bakal nggawe luwih angel kanggo panyerang kanggo ngeksploitasi XSS;
- mesin cithakan modern kayata Angular utawa React kanthi otomatis ngresiki data pangguna sadurunge dikirim menyang browser pangguna.
Kerentanan otentikasi rong faktor
Kanggo nambah keamanan akun, pangguna tansah disaranake kanggo ngaktifake 2FA (otentikasi rong faktor). Pancen, iki minangka cara sing efektif kanggo nyegah panyerang entuk akses menyang layanan yen kredensial pangguna wis dikompromi.
Nanging apa nggunakake faktor otentikasi kapindho mesthi njamin keamanan akun? Ana masalah keamanan ing ngisor iki ing implementasine 2FA:
- Panelusuran brute-force saka kode OTP (kode siji-wektu). Senadyan kesederhanaan operasi, kesalahan kayata kekurangan perlindungan marang OTP brute force uga ditemoni dening perusahaan gedhe: , .
- Algoritma generasi sing lemah, umpamane kemampuan kanggo prédhiksi kode sabanjure.
- Kesalahan logis, kayata kemampuan kanggo njaluk OTP wong liya ing telpon, kaya iki saka Shopify.
Ing kasus MCS, 2FA dileksanakake adhedhasar Google Authenticator lan . Protokol kasebut dhewe wis diuji wektu, nanging implementasine verifikasi kode ing sisih aplikasi kudu dipriksa.
MCS 2FA digunakake ing sawetara panggonan:
- Nalika otentikasi pangguna. Ana pangayoman marang pasukan kasar: pangguna mung duwe sawetara upaya kanggo ngetik sandhi siji-wektu, banjur input diblokir kanggo sawetara wektu. Iki ngalangi kemungkinan pilihan brute-force OTP.
- Nalika ngasilake kode serep offline kanggo nindakake 2FA, uga mateni. Ing kene, ora ana pangayoman brute force sing dileksanakake, sing ndadekake, yen sampeyan duwe sandhi kanggo akun lan sesi aktif, kanggo regenerasi kode serep utawa mateni 2FA rampung.
Ngelingi manawa kode serep kasebut ana ing sawetara nilai senar sing padha karo sing digawe dening aplikasi OTP, kemungkinan nemokake kode kasebut ing wektu sing cendhak luwih dhuwur.
Proses milih OTP kanggo mateni 2FA nggunakake alat "Burp: Intruder".
asil
Sakabèhé, MCS katon aman minangka produk. Sajrone audit, tim pentesting ora bisa entuk akses menyang VM klien lan data, lan kerentanan sing ditemokake kanthi cepet didandani dening tim MCS.
Nanging ing kene penting kanggo dicathet yen keamanan minangka karya sing terus-terusan. Layanan ora statis, terus berkembang. Lan ora bisa ngembangake produk kanthi lengkap tanpa kerentanan. Nanging sampeyan bisa nemokake ing wektu lan nyilikake kasempatan saka ambalan.
Saiki kabeh kerentanan sing kasebut ing MCS wis didandani. Lan supaya jumlah sing anyar minimal lan nyuda umure, tim platform terus nindakake iki:
- ajeg nindakake audit dening perusahaan eksternal;
- ndhukung lan ngembangaken partisipasi;
- melu keamanan. 🙂
Source: www.habr.com