Inok kaamanan tina platform awan MCS

SkyShip Magrib ku SeerLight

Ngawangun jasa naon waé kedah kalebet padamelan konstan dina kaamanan. Kaamanan mangrupikeun prosés kontinyu anu kalebet analisa konstan sareng perbaikan kaamanan produk, ngawaskeun warta ngeunaan kerentanan sareng seueur deui. Kaasup audits. Audits dilumangsungkeun boh di-imah jeung ku ahli éksternal, anu radikal bisa mantuan kalawan kaamanan sabab teu immersed dina proyék jeung boga pikiran kabuka.

Tulisan ieu ngeunaan pandangan anu paling lugas para ahli luar anu ngabantosan tim Mail.ru Cloud Solutions (MCS) nguji jasa awan, sareng ngeunaan naon anu aranjeunna mendakan. Salaku "kakuatan éksternal," MCS milih perusahaan Kaamanan Digital, anu dikenal ku kaahlian anu luhur dina bunderan kaamanan inpormasi. Sareng dina tulisan ieu kami bakal nganalisis sababaraha kerentanan anu pikaresepeun anu dipendakan salaku bagian tina Inok éksternal - supados anjeun ngahindarkeun rake anu sami nalika anjeun nyiptakeun jasa awan anjeun nyalira.

produk Pedaran

Mail.ru Cloud Solutions (MCS) nyaéta platform pikeun ngawangun infrastruktur maya dina awan. Éta kalebet IaaS, PaaS, sareng pasar gambar aplikasi anu siap-siap pikeun pamekar. Ningali arsitéktur MCS, éta kedah mariksa kasalametan produk di daérah ieu:

• ngajaga infrastruktur lingkungan virtualization: hypervisors, routing, firewalls;
• panyalindungan infrastruktur maya konsumén ': isolasi ti silih, kaasup jaringan, jaringan pribadi di SDN;
• OpenStack sareng komponenana kabuka;
• S3 desain urang sorangan;
• IAM: proyék multi-tenant sareng panutan;
• Visi (visi komputer): API sareng kerentanan nalika damel sareng gambar;
• panganteur wéb sareng serangan wéb klasik;
• kerentanan komponén PaaS;
• API sadaya komponén.

Panginten éta sadayana anu penting pikeun sajarah salajengna.

Jenis padamelan anu dilaksanakeun sareng naha éta diperyogikeun?

Inok kaamanan ditujukeun pikeun ngaidentipikasi kerentanan sareng kasalahan konfigurasi anu tiasa nyababkeun kabocoran data pribadi, modifikasi inpormasi sénsitip, atanapi gangguan kasadiaan jasa.

Salila damel, anu rata-rata 1-2 bulan, auditors ngulang deui tindakan panyerang poténsial sareng milarian kerentanan dina bagian klien sareng server tina jasa anu dipilih. Dina konteks audit platform awan MCS, tujuan ieu diidentifikasi:

1. Analisis auténtikasi dina jasa. Kerentanan dina komponén ieu bakal ngabantosan pikeun langsung asup kana rekening jalma sanés.
2. Diajar panutan sareng kontrol aksés antara akun anu béda. Pikeun panyerang, kamampuan pikeun ngakses mesin virtual batur mangrupikeun tujuan anu dipikahoyong.
3. Kerentanan sisi klien. XSS/CSRF/CRLF/jsb. Dupi éta mungkin pikeun nyerang pamaké séjén ngaliwatan tumbu jahat?
4. Kerentanan sisi server: RCE sareng sagala jinis suntikan (SQL / XXE / SSRF sareng saterasna). Kerentanan server umumna langkung hese milarian, tapi aranjeunna ngakibatkeun kompromi seueur pangguna sakaligus.
5. Analisis isolasi bagean pamaké dina tingkat jaringan. Pikeun panyerang, kurangna isolasi sacara signifikan ningkatkeun permukaan serangan ngalawan pangguna sanés.
6. Analisis logika bisnis. Naha mungkin pikeun nipu usaha sareng nyiptakeun mesin virtual gratis?

Dina proyék ieu, karya dilumangsungkeun nurutkeun model "Gray-kotak": auditors berinteraksi sareng jasa jeung hak husus pamaké biasa, tapi sawaréh miboga kodeu sumber API sarta miboga kasempetan pikeun netelakeun rinci jeung pamekar. Ieu biasana nu pangmerenahna, sarta dina waktos anu sareng rada realistis modél gawé: informasi internal masih bisa dikumpulkeun ku lawan, éta ngan hitungan waktos.

Vulnerabilities kapanggih

Sateuacan auditor publik mimiti ngirimkeun rupa-rupa payloads (payload dipaké pikeun ngalakukeun serangan) ka tempat acak, perlu ngartos kumaha hal jalan na naon pungsionalitas disadiakeun. Éta sigana yén ieu mangrupikeun latihan anu teu aya gunana, sabab dina kalolobaan tempat anu ditaliti moal aya kerentanan. Tapi ngan ukur ngartos struktur aplikasi sareng logika operasina bakal ngamungkinkeun anjeun mendakan vektor serangan anu paling kompleks.

Kadé pikeun manggihan tempat nu sigana curiga atanapi pisan béda ti batur dina sababaraha cara. Sareng kerentanan bahaya anu munggaran kapanggih ku cara ieu.

IDOR

Kerentanan IDOR (Referensi Objék Langsung Teu Aman) mangrupikeun salah sahiji kerentanan anu paling umum dina logika bisnis, anu ngamungkinkeun hiji atanapi anu sanés pikeun aksés kana objék anu henteu diidinan aksés. Kerentanan IDOR nyiptakeun kamungkinan pikeun meunangkeun inpormasi ngeunaan pangguna anu béda-béda tingkat kritis.

Salah sahiji pilihan IDOR nyaéta ngalakukeun tindakan sareng objék sistem (pamaké, rekening bank, barang dina karanjang balanja) ku ngamanipulasi identifier aksés ka objék ieu. Ieu ngakibatkeun konsékuansi paling unpredictable. Contona, kamungkinan ngaganti akun nu ngirim dana, ngaliwatan nu bisa maok eta ti pamaké séjén.

Dina kasus MCS, auditor nembé mendakan kerentanan IDOR anu aya hubunganana sareng idéntifikasi anu henteu aman. Dina akun pribadi pangguna, identifier UUID dianggo pikeun ngaksés obyék naon waé, anu sigana, sakumaha saur para ahli kaamanan, teu aman pisan (nyaéta, ditangtayungan tina serangan brute force). Tapi pikeun éntitas anu tangtu, kapanggih yén angka anu tiasa diprediksi biasa dianggo pikeun kéngingkeun inpormasi ngeunaan pangguna aplikasi. Jigana anjeun bisa nebak yén ieu mungkin pikeun ngarobah pamaké ID ku hiji, ngirim pamundut deui sahingga ménta informasi bypassing ACL (daptar kontrol aksés, aturan aksés data pikeun prosés jeung pamaké).

Pemalsuan Permintaan Sisi Server (SSRF)

Hal anu saé ngeunaan produk OpenSource nyaéta aranjeunna gaduh sajumlah ageung forum kalayan déskripsi téknis anu detil ngeunaan masalah anu timbul sareng, upami anjeun untung, pedaran ngeunaan solusi. Tapi koin ieu boga sisi flip: vulnerabilities dipikawanoh ogé dijelaskeun di jéntré. Contona, aya déskripsi éndah ngeunaan kerentanan dina forum OpenStack [XSS] и [SSRF], nu keur sababaraha alesan teu aya nu buru ngalereskeun.

Fungsi umum aplikasi nyaéta kamampuan pikeun pangguna ngirim tautan ka server, anu diklik ku server (contona, pikeun ngaunduh gambar tina sumber anu ditangtukeun). Upami alat kaamanan henteu nyaring tautan nyalira atanapi réspon anu dipulangkeun ti server ka pangguna, fungsionalitas sapertos kitu tiasa dianggo ku panyerang.

Kerentanan SSRF tiasa ngamajukeun ngembangkeun serangan. Panyerang tiasa nampi:

• aksés kawates ka jaringan lokal diserang, contona, ngan ngaliwatan bagéan jaringan nu tangtu sarta ngagunakeun protokol nu tangtu;
• aksés pinuh ka jaringan lokal, lamun downgrading ti tingkat aplikasi ka tingkat angkutan mungkin tur, salaku hasilna, manajemén beban pinuh di tingkat aplikasi;
• aksés pikeun maca file lokal dina server (upami file: // skéma dirojong);
• jeung leuwih.

Kerentanan SSRF geus lila dipikawanoh di OpenStack, nu "buta" di alam: mun anjeun ngahubungan server, anjeun teu nampa respon ti dinya, tapi anjeun nampi tipena béda kasalahan / reureuh, gumantung kana hasil pamundut. . Dumasar ieu, anjeun tiasa ngalakukeun scan port dina host dina jaringan internal, kalayan sagala konsékuansi ensuing nu teu matak underestimated. Contona, hiji produk bisa boga API back-office nu ngan bisa diasupan ti jaringan perusahaan. Kalayan dokuméntasi (ulah hilap ngeunaan insider), panyerang tiasa nganggo SSRF pikeun ngaksés metode internal. Salaku conto, upami anjeun kumaha waé tiasa kéngingkeun daptar perkiraan URL anu mangpaat, teras nganggo SSRF anjeun tiasa ngaliwat aranjeunna sareng ngalaksanakeun pamundut - sacara rélatif, mindahkeun artos tina akun ka akun atanapi ngarobih wates.

Ieu sanés pertama kalina kerentanan SSRF kapanggih dina OpenStack. Baheula, mungkin pikeun ngaunduh gambar VM ISO tina tautan langsung, anu ogé nyababkeun akibat anu sami. Fitur ieu ayeuna parantos dipiceun tina OpenStack. Tétéla, masarakat dianggap ieu solusi pangbasajanna jeung paling dipercaya pikeun masalah.

Jeung dina ieu laporan sadia masarakat awam ti jasa HackerOne (h1), eksploitasi SSRF euweuh buta kalawan kamampuhan pikeun maca metadata conto ngabalukarkeun aksés Akar ka sakabéh infrastruktur Shopify.

Dina MCS, kerentanan SSRF kapanggih dina dua tempat anu fungsina sami, tapi ampir teu mungkin dimanfaatkeun kusabab firewall sareng panyalindungan anu sanés. Hiji cara atanapi anu sanés, tim MCS ngalereskeun masalah ieu, tanpa ngantosan komunitas.

XSS tinimbang ngamuat cangkang

Sanajan ratusan studi ditulis, taun sanggeus taun XSS (cross-site scripting) serangan masih paling remen karandapan kerentanan wéb (atanapi narajang?).

Unggahan file mangrupikeun tempat anu dipikaresep pikeun panaliti kaamanan. Seringna tétéla yén anjeun tiasa ngamuat skrip sawenang (asp/jsp/php) sareng ngalaksanakeun paréntah OS, dina terminologi pentesters - "load shell". Tapi popularitas kerentanan sapertos dianggo dina dua arah: aranjeunna émut sareng pangobatan dikembangkeun ngalawan aranjeunna, ku kituna ayeuna kamungkinan "muatan cangkang" condong nol.

Tim narajang (diwakilan ku Digital Security) untung. OKÉ, dina MCS di sisi server eusi file diundeur dipariksa, ngan gambar anu diwenangkeun. Tapi SVG ogé gambar. Kumaha gambar SVG tiasa bahaya? Kusabab anjeun tiasa ngalebetkeun snippét JavaScript kana aranjeunna!

Tétéla yén file anu diunduh sayogi pikeun sadaya pangguna jasa MCS, anu hartosna kamungkinan pikeun nyerang pangguna awan sanés, nyaéta pangurus.

Conto serangan XSS dina formulir login phishing

Conto eksploitasi serangan XSS:

• Naha coba maok sési (utamana saprak ayeuna HTTP-Ngan cookies nu madhab, ditangtayungan tina maling maké Aksara js), lamun naskah dimuat bisa langsung ngakses API sumberdaya? Dina hal ieu, payload tiasa nganggo pamundut XHR pikeun ngarobih konfigurasi server, contona, nambihan konci SSH umum panyerang sareng kéngingkeun aksés SSH ka server.
• Upami kabijakan CSP (kabijakan panyalindungan eusi) ngalarang JavaScript pikeun disuntik, panyerang tiasa ngalangkungan tanpa éta. Ngagunakeun HTML murni, nyieun formulir login palsu pikeun situs jeung maok sandi administrator ngaliwatan phishing canggih ieu: kaca phishing pikeun pamaké ends nepi di URL sarua, sarta leuwih hese pikeun pamaké pikeun ngadeteksi eta.
• Tungtungna, panyerang tiasa ngatur klien DoS - set Cookies leuwih badag batan 4 KB. Pamaké ngan ukur kedah muka tautan sakali, sareng sadaya situs janten teu tiasa diaksés dugi ka pangguna mikir pikeun ngabersihan browser sacara khusus: dina kalolobaan kasus, pangladén wéb bakal nampik nampi klien sapertos kitu.

Hayu urang tingali conto XSS anu sanés anu dideteksi, waktos ieu kalayan garapan anu langkung pinter. Ladenan MCS ngidinan Anjeun pikeun ngagabungkeun setelan firewall kana grup. Ngaran grup éta tempat XSS dideteksi. Anu unik nyaéta yén vektor henteu langsung dipicu, sanés nalika ningali daptar aturan, tapi nalika ngahapus grup:

Nyaéta, skénario tétéla kieu: panyerang nyiptakeun aturan firewall kalayan nami "beban", kuncén perhatikeun saatos sababaraha waktos sareng ngamimitian prosés ngahapus. Sareng ieu dimana JS jahat jalanna.

Pikeun pamekar MCS, pikeun ngajaga ngalawan XSS dina gambar SVG anu diunduh (upami teu tiasa ditinggalkeun), tim Kaamanan Digital nyarankeun:

• Tempat file anu diunggah ku pangguna dina domain anu misah anu teu aya hubunganana sareng "cookies". Skrip bakal dieksekusi dina konteks domain anu béda sareng moal ngancem MCS.
• Dina réspon HTTP server, kirimkeun lulugu "Content-disposition: attachment". Teras file bakal diunduh ku browser sareng henteu dieksekusi.

Salaku tambahan, ayeuna aya seueur cara anu sayogi pikeun pamekar pikeun ngirangan résiko eksploitasi XSS:

• ngagunakeun "HTTP Ngan" bandéra, anjeun tiasa ngadamel sési "Cookies" headers inaccessible mun JavaScript jahat;
• leres dilaksanakeun kawijakan CSP bakal ngajantenkeun panyerang langkung sesah pikeun ngamangpaatkeun XSS;
• mesin citakan modern sapertos Angular atanapi React sacara otomatis ngabersihan data pangguna sateuacan kaluarkeun kana browser pangguna.

Kerentanan auténtikasi dua faktor

Pikeun ningkatkeun kaamanan akun, pangguna sok disarankan pikeun ngaktipkeun 2FA (auténtikasi dua faktor). Mémang, ieu mangrupikeun cara anu épéktip pikeun nyegah panyerang nampi aksés kana jasa upami kredensial pangguna parantos dikompromi.

Tapi naha ngagunakeun faktor auténtikasi kadua salawasna ngajamin kaamanan akun? Aya masalah kaamanan di handap ieu dina palaksanaan 2FA:

• Pilarian brute-force tina kode OTP (kode sakali). Sanaos kesederhanaan operasi, kasalahan sapertos kurangna panyalindungan ngalawan gaya kasar OTP ogé dipanggihan ku perusahaan ageung: Kasus Slack, Kasus Facebook.
• Algoritma generasi lemah, contona kamampuhan pikeun ngaduga kode salajengna.
• Kasalahan logis, sapertos kamampuan menta OTP batur dina telepon anjeun, sapertos kieu ieu ti Shopify.

Dina kasus MCS, 2FA dilaksanakeun dumasar kana Google Authenticator sareng duo. Protokol sorangan parantos diuji waktos, tapi palaksanaan verifikasi kode dina sisi aplikasi patut dipariksa.

MCS 2FA dianggo di sababaraha tempat:

• Nalika auténtikasi pangguna. Aya panyalindungan ngalawan gaya kasar: pamaké ngan boga sababaraha usaha pikeun nuliskeun kecap akses hiji-waktos, teras input diblokir sakedap. Ieu meungpeuk kamungkinan pilihan brute-force OTP.
• Nalika ngahasilkeun kode cadangan offline pikeun ngalakukeun 2FA, ogé nganonaktipkeun éta. Di dieu, teu aya panangtayungan gaya brute anu dilaksanakeun, anu ngamungkinkeun, upami anjeun ngagaduhan kecap konci pikeun akun sareng sési aktip, pikeun ngabangkitkeun kode cadangan atanapi nganonaktipkeun 2FA lengkep.

Nganggap yén kode cadangan ayana dina rentang nilai string anu sami sareng anu dihasilkeun ku aplikasi OTP, kasempetan pikeun mendakan kodeu dina waktos anu singget langkung luhur.

Prosés milih OTP pikeun nganonaktipkeun 2FA nganggo alat "Burp: Intruder".

hasil

Gemblengna, MCS sigana aman salaku produk. Salila pamariksaan, tim pentesting henteu tiasa nampi aksés ka VM klien sareng datana, sareng kerentanan anu dipendakan gancang dilereskeun ku tim MCS.

Tapi di dieu hal anu penting pikeun dicatet yén kaamanan mangrupa karya kontinyu. Jasa henteu statis, aranjeunna terus-terusan mekar. Sareng mustahil pikeun ngembangkeun produk lengkep tanpa kerentanan. Tapi anjeun tiasa mendakanana dina waktosna sareng ngaminimalkeun kamungkinan kambuhna.

Ayeuna sadaya kerentanan anu disebatkeun dina MCS parantos dilereskeun. Sareng pikeun ngaminimalkeun jumlah anu énggal sareng ngirangan umurna, tim platform terus ngalakukeun ieu:

• rutin ngalaksanakeun audits ku pausahaan éksternal;
• ngarojong sarta ngamekarkeun partisipasi dina program Mail.ru Group Bug Bounty;
• kalibet dina kaamanan. 🙂

sumber: www.habr.com