sa pamamagitan ng SeerLight
Ang pagbuo ng anumang serbisyo ay kinakailangang kasama ang patuloy na trabaho sa seguridad. Ang seguridad ay isang tuluy-tuloy na proseso na kinabibilangan ng patuloy na pagsusuri at pagpapabuti ng seguridad ng produkto, pagsubaybay sa mga balita tungkol sa mga kahinaan at marami pang iba. Kasama ang mga pag-audit. Ang mga pag-audit ay isinasagawa kapwa sa loob at labas ng mga eksperto, na maaaring makatulong sa seguridad dahil hindi sila nababaon sa proyekto at may bukas na isip.
Ang artikulo ay tungkol sa pinakasimpleng pananaw na ito ng mga external na eksperto na tumulong sa Mail.ru Cloud Solutions (MCS) team na subukan ang cloud service, at tungkol sa kung ano ang kanilang nahanap. Bilang isang "panlabas na puwersa," pinili ng MCS ang kumpanya ng Digital Security, na kilala sa mataas na kadalubhasaan nito sa mga lupon ng seguridad ng impormasyon. At sa artikulong ito susuriin namin ang ilang kawili-wiling mga kahinaan na natagpuan bilang bahagi ng isang panlabas na pag-audit - upang maiwasan mo ang parehong rake kapag lumikha ka ng iyong sariling serbisyo sa cloud.
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ ΠΏΡΠΎΠ΄ΡΠΊΡΠ°
ay isang platform para sa pagbuo ng virtual na imprastraktura sa cloud. Kabilang dito ang IaaS, PaaS, at isang marketplace ng mga yari na larawan ng application para sa mga developer. Isinasaalang-alang ang arkitektura ng MCS, kinakailangang suriin ang kaligtasan ng produkto sa mga sumusunod na lugar:
- pagprotekta sa imprastraktura ng virtualization environment: hypervisors, routing, firewalls;
- proteksyon ng virtual na imprastraktura ng mga customer: paghihiwalay sa isa't isa, kabilang ang network, pribadong network sa SDN;
- OpenStack at ang mga bukas na bahagi nito;
- S3 ng aming sariling disenyo;
- IAM: multi-tenant projects na may role model;
- Vision (computer vision): Mga API at mga kahinaan kapag nagtatrabaho sa mga larawan;
- web interface at mga klasikong pag-atake sa web;
- mga kahinaan ng mga bahagi ng PaaS;
- API ng lahat ng mga bahagi.
Marahil iyon lang ang mahalaga para sa karagdagang kasaysayan.
Anong uri ng trabaho ang isinagawa at bakit ito kailangan?
Ang pag-audit sa seguridad ay naglalayong tukuyin ang mga kahinaan at mga error sa pagsasaayos na maaaring humantong sa pagtagas ng personal na data, pagbabago ng sensitibong impormasyon, o pagkaantala sa availability ng serbisyo.
Sa panahon ng trabaho, na tumatagal sa average na 1-2 buwan, inuulit ng mga auditor ang mga aksyon ng mga potensyal na umaatake at naghahanap ng mga kahinaan sa mga bahagi ng kliyente at server ng napiling serbisyo. Sa konteksto ng pag-audit ng MCS cloud platform, natukoy ang mga sumusunod na layunin:
- Pagsusuri ng pagpapatunay sa serbisyo. Ang mga kahinaan sa bahaging ito ay makakatulong upang agad na makapasok sa mga account ng ibang tao.
- Pag-aaral ng role model at access control sa pagitan ng iba't ibang account. Para sa isang umaatake, ang kakayahang makakuha ng access sa virtual machine ng ibang tao ay isang kanais-nais na layunin.
- Mga kahinaan sa panig ng kliyente. XSS/CSRF/CRLF/atbp. Posible bang atakehin ang ibang mga user sa pamamagitan ng mga nakakahamak na link?
- Mga kahinaan sa gilid ng server: RCE at lahat ng uri ng iniksyon (SQL/XXE/SSRF at iba pa). Ang mga kahinaan ng server sa pangkalahatan ay mas mahirap hanapin, ngunit humahantong sila sa kompromiso ng maraming user nang sabay-sabay.
- Pagsusuri ng paghihiwalay ng segment ng user sa antas ng network. Para sa isang umaatake, ang kakulangan ng paghihiwalay ay lubos na nagpapataas ng pag-atake laban sa iba pang mga user.
- Pagsusuri ng lohika ng negosyo. Posible bang linlangin ang mga negosyo at lumikha ng mga virtual machine nang libre?
Sa proyektong ito, isinagawa ang trabaho ayon sa modelong "Gray-box": ang mga auditor ay nakipag-ugnayan sa serbisyo na may mga pribilehiyo ng mga ordinaryong gumagamit, ngunit bahagyang nagtataglay ng source code ng API at nagkaroon ng pagkakataong linawin ang mga detalye sa mga developer. Ito ay karaniwang ang pinaka-maginhawa, at sa parehong oras medyo makatotohanang modelo ng trabaho: ang panloob na impormasyon ay maaari pa ring kolektahin ng isang umaatake, ito ay isang oras lamang.
Natagpuan ang mga kahinaan
Bago simulan ng auditor ang pagpapadala ng iba't ibang mga payload (ang kargamento na ginamit upang isagawa ang pag-atake) sa mga random na lugar, kinakailangang maunawaan kung paano gumagana ang mga bagay at kung anong functionality ang ibinigay. Maaaring mukhang ito ay isang walang silbi na ehersisyo, dahil sa karamihan ng mga pinag-aralan na lugar ay walang mga kahinaan. Ngunit ang pag-unawa lamang sa istraktura ng application at ang lohika ng operasyon nito ay magiging posible upang mahanap ang pinaka kumplikadong mga vector ng pag-atake.
Mahalagang makahanap ng mga lugar na mukhang kahina-hinala o ibang-iba sa iba sa ilang paraan. At ang unang mapanganib na kahinaan ay natagpuan sa ganitong paraan.
IDOR
Ang mga kahinaan ng IDOR (Insecure Direct Object Reference) ay isa sa mga pinakakaraniwang kahinaan sa lohika ng negosyo, na nagbibigay-daan sa isa o iba pang makakuha ng access sa mga bagay kung saan hindi talaga pinahihintulutan ang pag-access. Ang mga kahinaan ng IDOR ay lumilikha ng posibilidad na makakuha ng impormasyon tungkol sa isang gumagamit na may iba't ibang antas ng pagiging kritikal.
Ang isa sa mga opsyon ng IDOR ay ang magsagawa ng mga aksyon sa mga object ng system (mga user, bank account, item sa shopping cart) sa pamamagitan ng pagmamanipula ng mga access identifier sa mga bagay na ito. Ito ay humahantong sa pinaka hindi mahuhulaan na mga kahihinatnan. Halimbawa, ang posibilidad na palitan ang account ng nagpadala ng mga pondo, kung saan maaari mong nakawin ang mga ito mula sa ibang mga gumagamit.
Sa kaso ng MCS, natuklasan ng mga auditor ang isang kahinaan ng IDOR na nauugnay sa mga hindi secure na identifier. Sa personal na account ng user, ang mga UUID identifier ay ginamit upang ma-access ang anumang mga bagay, na tila, tulad ng sinasabi ng mga eksperto sa seguridad, ay kahanga-hangang hindi secure (iyon ay, protektado mula sa mga malupit na pag-atake). Ngunit para sa ilang partikular na entity, natuklasan na ang mga regular na predictable na numero ay ginagamit upang makakuha ng impormasyon tungkol sa mga gumagamit ng application. Sa palagay ko maaari mong hulaan na posible na baguhin ang user ID ng isa, ipadala muli ang kahilingan at sa gayon ay makakuha ng impormasyon na lumalampas sa ACL (listahan ng kontrol sa pag-access, mga panuntunan sa pag-access ng data para sa mga proseso at mga gumagamit).
Pamemeke sa Server Side Request (SSRF)
Ang magandang bagay tungkol sa mga produkto ng OpenSource ay mayroon silang isang malaking bilang ng mga forum na may detalyadong teknikal na paglalarawan ng mga problema na lumitaw at, kung ikaw ay mapalad, isang paglalarawan ng solusyon. Ngunit ang coin na ito ay may flip side: ang mga kilalang kahinaan ay inilarawan din nang detalyado. Halimbawa, may mga magagandang paglalarawan ng mga kahinaan sa OpenStack forum ΠΈ , na sa ilang kadahilanan ay walang nagmamadaling ayusin.
Ang isang karaniwang pag-andar ng mga application ay ang kakayahan para sa user na magpadala ng isang link sa server, kung saan nag-click ang server (halimbawa, upang mag-download ng isang imahe mula sa isang tinukoy na pinagmulan). Kung hindi sinasala ng mga tool sa seguridad ang mga link mismo o ang mga tugon na ibinalik mula sa server sa mga user, madaling magamit ng mga umaatake ang naturang functionality.
Ang mga kahinaan ng SSRF ay maaaring lubos na magsulong ng pagbuo ng isang pag-atake. Ang isang umaatake ay maaaring makakuha ng:
- limitadong pag-access sa inaatakeng lokal na network, halimbawa, sa pamamagitan lamang ng ilang mga segment ng network at paggamit ng isang partikular na protocol;
- ganap na pag-access sa lokal na network, kung ang pag-downgrade mula sa antas ng aplikasyon sa antas ng transportasyon ay posible at, bilang resulta, ang buong pamamahala ng pagkarga sa antas ng aplikasyon;
- access upang basahin ang mga lokal na file sa server (kung sinusuportahan ang file:/// scheme);
- at marami pang iba.
Matagal nang kilala ang isang kahinaan sa SSRF sa OpenStack, na likas na "bulag": kapag nakipag-ugnayan ka sa server, hindi ka makakatanggap ng tugon mula dito, ngunit nakakatanggap ka ng iba't ibang uri ng mga error/pagkaantala, depende sa resulta ng kahilingan . Batay dito, maaari kang magsagawa ng port scan sa mga host sa panloob na network, kasama ang lahat ng kasunod na mga kahihinatnan na hindi dapat maliitin. Halimbawa, ang isang produkto ay maaaring may back-office API na naa-access lamang mula sa corporate network. Gamit ang dokumentasyon (huwag kalimutan ang tungkol sa mga tagaloob), ang isang umaatake ay maaaring gumamit ng SSRF upang ma-access ang mga panloob na pamamaraan. Halimbawa, kung sa paanuman ay nakakuha ka ng tinatayang listahan ng mga kapaki-pakinabang na URL, pagkatapos gamit ang SSRF maaari kang dumaan sa mga ito at magsagawa ng isang kahilingan - medyo nagsasalita, maglipat ng pera mula sa account patungo sa account o baguhin ang mga limitasyon.
Hindi ito ang unang pagkakataon na natuklasan ang kahinaan ng SSRF sa OpenStack. Noong nakaraan, posibleng mag-download ng mga imahe ng VM ISO mula sa isang direktang link, na humantong din sa mga katulad na kahihinatnan. Ang tampok na ito ay inalis na ngayon sa OpenStack. Tila, itinuturing ng komunidad na ito ang pinakasimple at pinaka-maaasahang solusyon sa problema.
At sa ulat na available sa publiko mula sa serbisyo ng HackerOne (h1), ang pagsasamantala sa isang hindi na bulag na SSRF na may kakayahang magbasa ng metadata ng instance ay humahantong sa Root access sa buong imprastraktura ng Shopify.
Sa MCS, natuklasan ang mga kahinaan ng SSRF sa dalawang lugar na may magkatulad na pag-andar, ngunit halos imposible itong pagsamantalahan dahil sa mga firewall at iba pang mga proteksyon. Sa isang paraan o iba pa, inayos pa rin ng koponan ng MCS ang problemang ito, nang hindi naghihintay sa komunidad.
XSS sa halip na mag-load ng mga shell
Sa kabila ng daan-daang pag-aaral na isinulat, taon-taon ang XSS (cross-site scripting) na pag-atake ay ang pinakamarami pa rin kahinaan sa web (o ?).
Ang mga pag-upload ng file ay isang paboritong lugar para sa sinumang mananaliksik ng seguridad. Madalas na lumalabas na maaari kang mag-load ng isang arbitrary na script (asp/jsp/php) at magsagawa ng mga utos ng OS, sa terminolohiya ng mga pentesters - "load shell". Ngunit ang katanyagan ng gayong mga kahinaan ay gumagana sa parehong direksyon: ang mga ito ay naaalala at ang mga remedyo ay binuo laban sa kanila, kaya kamakailan lamang ang posibilidad ng "pag-load ng isang shell" ay may posibilidad na zero.
Ang umaatake na koponan (kinakatawan ng Digital Security) ay mapalad. OK, sa MCS sa gilid ng server ang mga nilalaman ng mga na-download na file ay nasuri, mga larawan lamang ang pinapayagan. Ngunit ang SVG ay isang larawan din. Paano mapanganib ang mga larawang SVG? Dahil maaari mong i-embed ang mga snippet ng JavaScript sa mga ito!
Ito ay lumabas na ang mga na-download na file ay magagamit sa lahat ng mga gumagamit ng serbisyo ng MCS, na nangangahulugang posible na atakehin ang iba pang mga gumagamit ng ulap, lalo na ang mga administrator.
Isang halimbawa ng isang XSS attack sa isang phishing login form
Mga halimbawa ng XSS attack exploitation:
- Bakit subukang magnakaw ng session (lalo na dahil ngayon ang HTTP-Only na cookies ay nasa lahat ng dako, protektado mula sa pagnanakaw gamit ang mga js script), kung ang na-load na script ay maaaring agad na ma-access ang resource API? Sa kasong ito, maaaring gamitin ng payload ang mga kahilingan ng XHR para baguhin ang configuration ng server, halimbawa, idagdag ang pampublikong SSH key ng umaatake at makakuha ng SSH access sa server.
- Kung ang patakaran ng CSP (patakaran sa proteksyon ng nilalaman) ay nagbabawal sa JavaScript na mai-inject, makakaligtas ang isang umaatake nang wala ito. Gamit ang purong HTML, gumawa ng pekeng form sa pag-log in para sa site at nakawin ang password ng administrator sa pamamagitan ng advanced na phishing na ito: ang pahina ng phishing para sa user ay mapupunta sa parehong URL, at mas mahirap para sa user na matukoy ito.
- Sa wakas, makakaayos na ang umaatake β magtakda ng Cookies na mas malaki sa 4 KB. Kailangan lang ng user na buksan ang link nang isang beses, at ang buong site ay magiging hindi naa-access hanggang sa maisip ng user na partikular na linisin ang browser: sa karamihan ng mga kaso, tatanggi ang web server na tanggapin ang ganoong kliyente.
Tingnan natin ang isang halimbawa ng isa pang nakitang XSS, sa pagkakataong ito na may mas matalinong pagsasamantala. Binibigyang-daan ka ng serbisyo ng MCS na pagsamahin ang mga setting ng firewall sa mga grupo. Ang pangalan ng grupo ay kung saan natukoy ang XSS. Ang kakaiba nito ay ang vector ay hindi na-trigger kaagad, hindi kapag tinitingnan ang listahan ng mga panuntunan, ngunit kapag nagtanggal ng isang grupo:
Iyon ay, ang senaryo ay naging ang mga sumusunod: ang isang umaatake ay lumikha ng isang panuntunan sa firewall na may "load" sa pangalan, napansin ito ng administrator pagkatapos ng ilang sandali at sinimulan ang proseso ng pagtanggal. At dito gumagana ang malisyosong JS.
Para maprotektahan ng mga developer ng MCS laban sa XSS sa mga na-upload na SVG na larawan (kung hindi sila maaaring tanggalin), inirerekomenda ng Digital Security team ang:
- Ilagay ang mga file na na-upload ng mga user sa isang hiwalay na domain na walang kinalaman sa "cookies". Ang script ay isasagawa sa konteksto ng ibang domain at hindi maglalagay ng banta sa MCS.
- Sa tugon ng HTTP ng server, ipadala ang header na "Content-disposition: attachment." Pagkatapos ang mga file ay ida-download ng browser at hindi isasagawa.
Bilang karagdagan, mayroon na ngayong maraming paraan na magagamit ng mga developer para mabawasan ang mga panganib ng pagsasamantala ng XSS:
- gamit ang flag na "HTTP Lang", maaari mong gawing hindi naa-access ang mga header ng "Cookies" ng session sa nakakahamak na JavaScript;
- gagawing mas mahirap para sa isang umaatake na pagsamantalahan ang XSS;
- Awtomatikong nililinis ng mga modernong template engine gaya ng Angular o React ang data ng user bago ito i-output sa browser ng user.
Mga kahinaan sa two-factor authentication
Upang mapabuti ang seguridad ng account, palaging pinapayuhan ang mga user na paganahin ang 2FA (two-factor authentication). Sa katunayan, ito ay isang epektibong paraan upang pigilan ang isang umaatake na magkaroon ng access sa isang serbisyo kung ang mga kredensyal ng user ay nakompromiso.
Ngunit palaging ginagarantiyahan ba ng paggamit ng pangalawang salik sa pagpapatotoo ang kaligtasan ng account? Mayroong mga sumusunod na isyu sa seguridad sa pagpapatupad ng 2FA:
- Brute-force na paghahanap ng OTP code (mga one-time na code). Sa kabila ng pagiging simple ng operasyon, ang mga error tulad ng kawalan ng proteksyon laban sa OTP brute force ay nakatagpo din ng malalaking kumpanya: , .
- Mahinang generation algorithm, halimbawa ang kakayahang mahulaan ang susunod na code.
- Mga lohikal na error, gaya ng kakayahang humiling ng OTP ng ibang tao sa iyong telepono, tulad nito mula sa Shopify.
Sa kaso ng MCS, ipinatupad ang 2FA batay sa Google Authenticator at . Ang protocol mismo ay nasubok na sa oras, ngunit ang pagpapatupad ng pag-verify ng code sa panig ng aplikasyon ay sulit na suriin.
Ginagamit ang MCS 2FA sa ilang lugar:
- Kapag pinapatotohanan ang gumagamit. Mayroong proteksyon laban sa malupit na puwersa: ang gumagamit ay mayroon lamang ilang mga pagtatangka na magpasok ng isang beses na password, pagkatapos ay ang input ay na-block nang ilang sandali. Hinaharangan nito ang posibilidad ng malupit na pagpili ng OTP.
- Kapag bumubuo ng mga offline na backup na code upang maisagawa ang 2FA, pati na rin ang hindi pagpapagana nito. Dito, walang ipinatupad na brute force na proteksyon, na naging posible, kung mayroon kang password para sa account at isang aktibong session, upang muling buuin ang mga backup na code o ganap na i-disable ang 2FA.
Isinasaalang-alang na ang mga backup na code ay matatagpuan sa parehong hanay ng mga halaga ng string tulad ng nabuo ng OTP application, ang pagkakataon na mahanap ang code sa maikling panahon ay mas mataas.
Ang proseso ng pagpili ng isang OTP upang i-disable ang 2FA gamit ang tool na "Burp: Intruder".
Resulta
Sa pangkalahatan, mukhang ligtas ang MCS bilang isang produkto. Sa panahon ng pag-audit, ang pentesting team ay hindi nakakuha ng access sa mga client VM at sa kanilang data, at ang mga nakitang kahinaan ay mabilis na naitama ng MCS team.
Ngunit dito mahalagang tandaan na ang seguridad ay isang tuluy-tuloy na gawain. Ang mga serbisyo ay hindi static, sila ay patuloy na nagbabago. At imposibleng bumuo ng isang produkto nang ganap na walang mga kahinaan. Ngunit maaari mong mahanap ang mga ito sa oras at mabawasan ang pagkakataon ng kanilang pag-ulit.
Ngayon lahat ng nabanggit na mga kahinaan sa MCS ay naayos na. At para mapanatiling minimum ang bilang ng mga bago at mabawasan ang kanilang buhay, patuloy itong ginagawa ng platform team:
- regular na nagsasagawa ng mga pag-audit ng mga panlabas na kumpanya;
- suportahan at paunlarin ang pakikilahok;
- makisali sa seguridad. π
Pinagmulan: www.habr.com