SeerLight
Аливаа үйлчилгээг бий болгоход аюулгүй байдлын байнгын ажил орно. Аюулгүй байдал нь бүтээгдэхүүний аюулгүй байдлын байнгын дүн шинжилгээ, сайжруулалт, эмзэг байдлын талаарх мэдээг хянах болон бусад олон зүйлийг багтаасан тасралтгүй үйл явц юм. Үүнд аудит орно. Аудитыг дотооддоо болон гадны мэргэжилтнүүд хийдэг бөгөөд тэд төсөлд хамрагдаагүй, нээлттэй сэтгэлгээтэй тул аюулгүй байдлыг хангахад эрс тусалж чадна.
Энэхүү нийтлэл нь Mail.ru Cloud Solutions (MCS) багт үүлэн үйлчилгээг туршихад тусалсан гадны мэргэжилтнүүдийн хамгийн энгийн үзэл бодол болон тэдний олж мэдсэн зүйлийн тухай юм. М-Си-Эс нь "гадны хүч"-ийн хувьд мэдээллийн аюулгүй байдлын чиглэлээр өндөр мэргэшсэн гэдгээрээ алдартай Digital Security компанийг сонгосон. Мөн энэ нийтлэлд бид гадны аудитын нэг хэсэг болох сонирхолтой сул талуудад дүн шинжилгээ хийх болно - ингэснээр та өөрийн үүлэн үйлчилгээг бий болгохдоо ижил тармуураас зайлсхийх болно.
Описание продукта
нь үүлэн дээр виртуал дэд бүтцийг бий болгох платформ юм. Үүнд IaaS, PaaS болон хөгжүүлэгчдэд зориулсан бэлэн хэрэглээний зургийн зах зээл багтсан. MCS-ийн архитектурыг харгалзан бүтээгдэхүүний аюулгүй байдлыг дараахь чиглэлээр шалгах шаардлагатай байв.
- виртуалчлалын орчны дэд бүтцийг хамгаалах: гипервизор, чиглүүлэлт, галт хана;
- үйлчлүүлэгчдийн виртуал дэд бүтцийг хамгаалах: бие биенээсээ тусгаарлах, үүнд сүлжээ, SDN дахь хувийн сүлжээ;
- OpenStack болон түүний нээлттэй бүрэлдэхүүн хэсгүүд;
- S3 бидний өөрийн загвар;
- IAM: үлгэр дуурайлал бүхий олон түрээслэгчтэй төслүүд;
- Алсын хараа (компьютерийн хараа): API болон зурагтай ажиллах үеийн эмзэг байдал;
- вэб интерфэйс ба сонгодог вэб халдлага;
- PaaS бүрэлдэхүүн хэсгүүдийн эмзэг байдал;
- Бүх бүрэлдэхүүн хэсгүүдийн API.
Магадгүй энэ нь цаашдын түүхэнд зайлшгүй шаардлагатай бүх зүйл юм.
Ямар ажил хийсэн, яагаад хэрэгтэй байсан бэ?
Аюулгүй байдлын аудит нь хувийн мэдээлэл задрах, нууц мэдээллийг өөрчлөх, үйлчилгээний хүртээмжийг тасалдуулахад хүргэж болзошгүй эмзэг байдал, тохиргооны алдааг илрүүлэхэд чиглэгддэг.
Дунджаар 1-2 сар үргэлжилдэг ажлын явцад аудиторууд болзошгүй халдагчдын үйлдлийг давтаж, сонгосон үйлчилгээний үйлчлүүлэгч болон серверийн хэсгүүдийн сул талыг хайж байдаг. MCS үүлэн платформд хийсэн аудитын хүрээнд дараах зорилтуудыг тодорхойлсон.
- Үйлчилгээнд баталгаажуулалтын дүн шинжилгээ. Энэ бүрэлдэхүүн хэсгийн эмзэг байдал нь бусад хүмүүсийн данс руу шууд ороход тусална.
- Өөр өөр дансны хооронд үлгэр дуурайлал, хандалтын хяналтыг судлах. Халдагчийн хувьд хэн нэгний виртуал машин руу нэвтрэх чадвар нь хүсүүштэй зорилго юм.
- Үйлчлүүлэгчийн талын эмзэг байдал. XSS/CSRF/CRLF/ гэх мэт. Хортой холбоосоор дамжуулан бусад хэрэглэгчдэд халдах боломжтой юу?
- Серверийн сул талууд: RCE болон бүх төрлийн тарилга (SQL/XXE/SSRF гэх мэт). Серверийн сул талуудыг олоход ерөнхийдөө илүү хэцүү байдаг ч энэ нь олон хэрэглэгчийг нэгэн зэрэг эвдэхэд хүргэдэг.
- Сүлжээний түвшинд хэрэглэгчийн сегментийг тусгаарлах шинжилгээ. Халдагчийн хувьд тусгаарлалт байхгүй байгаа нь бусад хэрэглэгчдийн эсрэг халдлагын гадаргууг ихээхэн нэмэгдүүлдэг.
- Бизнесийн логик шинжилгээ. Бизнесүүдийг хууран мэхэлж, виртуал машиныг үнэгүй бий болгох боломжтой юу?
Энэхүү төсөлд "Саарал хайрцаг" загварын дагуу ажил хийгдсэн: аудиторууд энгийн хэрэглэгчдийн давуу эрхээр үйлчилгээтэй харилцаж байсан боловч API-ийн эх кодыг хэсэгчлэн эзэмшиж, хөгжүүлэгчидтэй дэлгэрэнгүй мэдээллийг тодруулах боломжтой болсон. Энэ нь ихэвчлэн хамгийн тохиромжтой бөгөөд нэгэн зэрэг бодит ажлын загвар юм: дотоод мэдээллийг халдагчид цуглуулж болно, энэ нь зөвхөн цаг хугацааны асуудал юм.
Эмзэг байдал илэрсэн
Аудитор янз бүрийн ачааллыг (халдлага хийхэд ашигладаг ачааллыг) санамсаргүй газар руу илгээж эхлэхээс өмнө бүх зүйл хэрхэн ажилладаг, ямар функцээр хангагдсаныг ойлгох шаардлагатай. Энэ нь ашиггүй дасгал юм шиг санагдаж магадгүй, учир нь ихэнх судлагдсан газруудад эмзэг байдал байхгүй болно. Гэхдээ зөвхөн програмын бүтэц, түүний үйлдлийн логикийг ойлгох нь хамгийн төвөгтэй халдлагын векторуудыг олох боломжийг олгоно.
Сэжигтэй мэт санагдах эсвэл зарим талаараа бусдаас эрс ялгаатай газруудыг олох нь чухал юм. Анхны аюултай эмзэг байдлыг ийм байдлаар олж мэдсэн.
IDOR
IDOR (Аюулгүй шууд объектын лавлагаа) эмзэг байдал нь бизнесийн логикийн хамгийн түгээмэл сул талуудын нэг бөгөөд тэдгээр нь нэвтрэх боломжгүй объектуудад хандах боломжийг олгодог. IDOR-ийн эмзэг байдал нь янз бүрийн түвшний шүүмжлэлийн хэрэглэгчийн талаарх мэдээллийг олж авах боломжийг бий болгодог.
IDOR-ийн сонголтуудын нэг нь системийн объектуудтай (хэрэглэгчид, банкны дансууд, сагсанд байгаа зүйлс) эдгээр объект руу нэвтрэх танигчийг удирдах замаар үйлдэл хийх явдал юм. Энэ нь хамгийн урьдчилан таамаглах аргагүй үр дагаварт хүргэдэг. Жишээлбэл, мөнгө илгээгчийн дансыг солих боломжтой бөгөөд үүгээрээ дамжуулан та бусад хэрэглэгчдээс хулгайлж болно.
MCS-ийн хувьд аудиторууд аюулгүй бус танигчтай холбоотой IDOR-ийн эмзэг байдлыг дөнгөж илрүүлсэн. Хэрэглэгчийн хувийн дансанд UUID танигчийг ямар ч объект руу нэвтрэхэд ашигладаг байсан бөгөөд энэ нь аюулгүй байдлын мэргэжилтнүүдийн үзэж байгаагаар маш найдвартай биш юм шиг санагдаж байсан (өөрөөр хэлбэл харгис хүчний халдлагаас хамгаалагдсан). Гэхдээ зарим аж ахуйн нэгжүүдийн хувьд програмын хэрэглэгчдийн талаарх мэдээллийг авахын тулд урьдчилан таамаглах боломжтой тоонуудыг ашигладаг болохыг олж мэдсэн. Хэрэглэгчийн ID-г нэгээр сольж, хүсэлтийг дахин илгээж, улмаар ACL-ийг (хандах хяналтын жагсаалт, процесс, хэрэглэгчдэд зориулсан өгөгдөлд нэвтрэх дүрэм) тойрч мэдээлэл авах боломжтой байсан гэж та бодож байна.
Сервер талын хүсэлтийг хуурамчаар үйлдэх (SSRF)
OpenSource бүтээгдэхүүний сайн тал нь тэдгээр нь гарч ирж буй асуудлуудын техникийн нарийвчилсан тайлбар, хэрэв та азтай бол шийдлийн тайлбар бүхий асар олон тооны форумтай байдаг. Гэхдээ энэ зоос нь эсрэг талтай: мэдэгдэж буй сул талуудыг мөн нарийвчлан тайлбарласан болно. Жишээлбэл, OpenStack форум дээр эмзэг байдлын талаархи гайхалтай тайлбарууд байдаг и , ямар нэг шалтгааны улмаас хэн ч засах гэж яардаггүй.
Аппликешнүүдийн нийтлэг функц нь хэрэглэгч сервер дээр дарах холбоосыг сервер рүү илгээх чадвар юм (жишээлбэл, тодорхой эх сурвалжаас зураг татаж авах). Аюулгүй байдлын хэрэгслүүд нь холбоосуудыг өөрсдөө эсвэл серверээс хэрэглэгчдэд буцааж өгсөн хариултуудыг шүүдэггүй бол ийм функцийг халдагчид хялбархан ашиглаж болно.
SSRF-ийн эмзэг байдал нь халдлагыг хөгжүүлэхэд ихээхэн түлхэц болно. Халдагч дараахь зүйлийг авах боломжтой.
- халдлагад өртсөн дотоод сүлжээнд нэвтрэх хязгаарлагдмал, жишээлбэл, зөвхөн тодорхой сүлжээний сегментүүд болон тодорхой протокол ашиглан;
- хэрэв хэрэглээний түвшингээс тээврийн түвшин рүү шилжих боломжтой бол дотоод сүлжээнд бүрэн нэвтрэх боломжтой бөгөөд үүний үр дүнд хэрэглээний түвшинд ачааллыг бүрэн удирдах боломжтой;
- сервер дээрх локал файлуудыг унших хандалт (хэрэв файл: /// схемийг дэмждэг бол);
- ба түүнээс дээш.
SSRF-ийн эмзэг байдал нь OpenStack-д эрт дээр үеэс мэдэгдэж байсан бөгөөд энэ нь "харалган" шинж чанартай: сервертэй холбогдоход та түүнээс хариу хүлээж авдаггүй, гэхдээ хүсэлтийн үр дүнгээс хамааран өөр өөр төрлийн алдаа/саатал хүлээн авдаг. . Үүний үндсэн дээр та дотоод сүлжээн дэх хостууд дээр порт скан хийх боломжтой бөгөөд үүнээс үүдэн гарах бүх үр дагаврыг дутуу үнэлж болохгүй. Жишээлбэл, бүтээгдэхүүн нь зөвхөн корпорацийн сүлжээнээс хандах боломжтой арын албаны API-тай байж болно. Баримт бичгийн тусламжтайгаар (интерсайдын талаар бүү мартаарай) халдагчид SSRF-г ашиглан дотоод аргуудад хандах боломжтой. Жишээлбэл, хэрэв та ямар нэгэн байдлаар хэрэгцээтэй URL-уудын ойролцоо жагсаалтыг олж авах боломжтой байсан бол SSRF-ийг ашигласнаар та тэдгээрийг дамжуулж, хүсэлтийг гүйцэтгэх боломжтой - харьцангуйгаар данснаас данс руу мөнгө шилжүүлэх эсвэл хязгаарыг өөрчлөх боломжтой.
Энэ нь OpenStack дээр SSRF-ийн эмзэг байдлыг илрүүлсэн анхны тохиолдол биш юм. Өмнө нь VM ISO дүрсийг шууд холбоосоор татаж авах боломжтой байсан бөгөөд энэ нь мөн адил үр дагаварт хүргэсэн. Энэ функцийг одоо OpenStack-аас устгасан. Энэ нь асуудлыг шийдэх хамгийн энгийн бөгөөд найдвартай шийдэл гэж олон нийт үзсэн бололтой.
Тэгээд бас HackerOne үйлчилгээний (h1) олон нийтэд нээлттэй тайлан, жишээ мета өгөгдлийг унших чадвартай SSRF-ийг ашиглах боломжгүй болсон нь Shopify дэд бүтцэд Root хандалт хийхэд хүргэдэг.
MCS-д SSRF-ийн эмзэг байдлыг ижил төстэй ажиллагаатай хоёр газраас илрүүлсэн боловч галт хана болон бусад хамгаалалтын улмаас ашиглах бараг боломжгүй байв. Ямартай ч М-Си-Эс-ийн баг хамт олныг хүлээлгүйгээр энэ асуудлыг зассан.
Бүрхүүлийг ачаалахын оронд XSS
Олон зуун судалгаа бичсэн хэдий ч жилээс жилд XSS (сайт хоорондын скрипт) халдлага хамгийн их байсаар байна вэб эмзэг байдал (эсвэл ?)
Файл байршуулах нь аливаа аюулгүй байдлын судлаачдын дуртай газар юм. Та дурын скриптийг (asp/jsp/php) ачаалж, үйлдлийн системийн командуудыг "ачаалах бүрхүүл" гэсэн нэр томъёогоор гүйцэтгэх боломжтой болох нь олонтаа тохиолддог. Гэхдээ ийм эмзэг байдлын түгээмэл байдал нь хоёр чиглэлд ажилладаг: тэдгээрийг санаж, тэдгээрийн эсрэг арга хэмжээ авдаг тул сүүлийн үед "бүрхүүл ачаалах" магадлал тэг болж байна.
Довтолгооны баг (Digital Security-ээр төлөөлдөг) азтай байсан. За, сервер талд байгаа MCS-д татаж авсан файлуудын агуулгыг шалгасан, зөвхөн зураг оруулахыг зөвшөөрсөн. Гэхдээ SVG бол бас зураг юм. SVG зураг хэрхэн аюултай байж болох вэ? Учир нь та тэдгээрт JavaScript хэсгүүдийг оруулах боломжтой!
Татаж авсан файлууд нь MCS үйлчилгээний бүх хэрэглэгчдэд нээлттэй байгаа нь бусад үүлэн хэрэглэгчид, тухайлбал админ руу халдах боломжтой гэсэн үг юм.
Фишинг нэвтрэх маягт дээр XSS халдлагын жишээ
XSS халдлагын мөлжлөгийн жишээ:
- Ачаалагдсан скрипт нь API эх сурвалж руу шууд хандах боломжтой бол яагаад сесс хулгайлах гэж оролдох хэрэгтэй вэ (ялангуяа одоо бол зөвхөн HTTP күүки хаа сайгүй байгаа бөгөөд js скрипт ашиглан хулгайлахаас хамгаалагдсан)? Энэ тохиолдолд ачаалал нь XHR хүсэлтийг ашиглан серверийн тохиргоог өөрчлөх боломжтой, жишээлбэл халдагчийн нийтийн SSH түлхүүрийг нэмж, серверт SSH хандалт авах боломжтой.
- Хэрэв CSP бодлого (агуулгын хамгаалалтын бодлого) нь JavaScript-г оруулахыг хориглодог бол халдагч үүнгүйгээр даван туулж чадна. Цэвэр HTML ашиглан сайтад хуурамч нэвтрэх маягт үүсгэж, администраторын нууц үгийг энэхүү дэвшилтэт фишингээр хулгайлна уу: хэрэглэгчийн фишинг хуудас нь ижил URL дээр дуусдаг бөгөөд хэрэглэгч үүнийг илрүүлэхэд илүү хэцүү байдаг.
- Эцэст нь халдагч зохион байгуулж чадна — 4 КБ-аас их хэмжээтэй күүки тохируулна уу. Хэрэглэгч зөвхөн нэг удаа холбоосыг нээхэд хангалттай бөгөөд хэрэглэгч хөтчийг тусгайлан цэвэрлэхээр бодох хүртэл бүх сайтад нэвтрэх боломжгүй болно: ихэнх тохиолдолд вэб сервер ийм үйлчлүүлэгчийг хүлээн авахаас татгалздаг.
Өөр нэг илрүүлсэн XSS-ийн жишээг харцгаая, энэ удаад илүү ухаалаг ашиглах боломжтой. MCS үйлчилгээ нь танд галт ханын тохиргоог бүлэг болгон нэгтгэх боломжийг олгодог. Бүлгийн нэр нь XSS-г илрүүлсэн газар байсан. Үүний онцлог нь дүрмийн жагсаалтыг харах үед биш харин бүлгийг устгах үед вектор шууд идэвхждэггүй байв.
Өөрөөр хэлбэл, хувилбар нь дараах байдалтай болсон: халдагчид нэр дээрээ "ачаалал"-тай галт ханын дүрмийг үүсгэдэг бөгөөд администратор үүнийг хэсэг хугацааны дараа анзаарч, устгах үйл явцыг эхлүүлдэг. Энд л хортой JS ажилладаг.
MCS-ийн хөгжүүлэгчдэд татаж авсан SVG зураг дээрх XSS-ээс хамгаалахын тулд (хэрэв тэдгээрийг орхих боломжгүй бол) Дижитал Хамгаалалтын баг дараахыг зөвлөж байна:
- Хэрэглэгчдийн байршуулсан файлуудыг "күүки"-тэй ямар ч холбоогүй тусдаа домэйн дээр байрлуул. Скрипт нь өөр домэйны хүрээнд хийгдэх бөгөөд MCS-д аюул учруулахгүй.
- Серверийн HTTP хариултанд "Content-disposition: хавсралт" толгой хэсгийг илгээнэ үү. Дараа нь файлуудыг хөтчөөс татаж авах бөгөөд ажиллахгүй болно.
Нэмж дурдахад XSS-ийн ашиглалтын эрсдлийг бууруулах олон арга бий.
- "Зөвхөн HTTP" тугийг ашиглан та "Күүки" сессийн толгойг хортой JavaScript-д хандах боломжгүй болгож болно;
- халдагчид XSS-г ашиглахад илүү хэцүү болно;
- Angular эсвэл React зэрэг орчин үеийн загвар хөдөлгүүрүүд нь хэрэглэгчийн өгөгдлийг хэрэглэгчийн хөтөч рүү гаргахын өмнө автоматаар ариутгадаг.
Хоёр хүчин зүйлийн баталгаажуулалтын сул тал
Бүртгэлийн аюулгүй байдлыг сайжруулахын тулд хэрэглэгчдэд 2FA (хоёр хүчин зүйлийн баталгаажуулалтыг) идэвхжүүлэхийг үргэлж зөвлөж байна. Үнэн хэрэгтээ энэ нь хэрэглэгчийн итгэмжлэлд халдсан тохиолдолд халдагчийг үйлчилгээнд нэвтрэхээс урьдчилан сэргийлэх үр дүнтэй арга юм.
Гэхдээ хоёр дахь баталгаажуулалтын хүчин зүйлийг ашиглах нь үргэлж дансны аюулгүй байдлыг баталгаажуулдаг уу? 2FA-г хэрэгжүүлэхэд дараах аюулгүй байдлын асуудлууд тулгардаг.
- OTP кодыг харгис хүчээр хайх (нэг удаагийн код). Ашиглалтын энгийн байдлаас үл хамааран OTP харгис хэрцгий хүчнээс хамгаалалт дутмаг зэрэг алдаанууд томоохон компаниудад тулгардаг. , .
- Сул үеийн алгоритм, жишээлбэл, дараагийн кодыг урьдчилан таамаглах чадвар.
- Таны утсан дээр хэн нэгний OTP хүсэлт гаргах гэх мэт логик алдаанууд үүнтэй төстэй Shopify-аас.
MCS-ийн хувьд 2FA нь Google Authenticator болон . Протокол нь өөрөө аль хэдийн цаг хугацаагаар шалгагдсан боловч програмын тал дээр код баталгаажуулалтын хэрэгжилтийг шалгах нь зүйтэй.
MCS 2FA-г хэд хэдэн газар ашигладаг:
- Хэрэглэгчийг баталгаажуулах үед. Харгис хэрцгий хүчнээс хамгаалах хамгаалалт байдаг: хэрэглэгч нэг удаагийн нууц үг оруулахыг цөөн хэдэн оролдлого хийдэг бөгөөд дараа нь оролтыг хэсэг хугацаанд хаадаг. Энэ нь OTP-г бүдүүлэг хүчээр сонгох боломжийг хаадаг.
- 2FA гүйцэтгэхийн тулд офлайн нөөц код үүсгэх, мөн үүнийг идэвхгүй болгох үед. Энд ямар ч харгис хүчний хамгаалалт хийгдээгүй бөгөөд хэрэв та дансны нууц үг, идэвхтэй сесстэй бол нөөц кодыг сэргээх эсвэл 2FA-г бүрэн идэвхгүй болгох боломжтой болсон.
Нөөц кодууд нь OTP програмаар үүсгэгдсэн утгын ижил мужид байрлаж байсан тул кодыг богино хугацаанд олох боломж хамаагүй өндөр байв.
"Burp: Intruder" хэрэглүүрийг ашиглан 2FA-г идэвхгүй болгох OTP сонгох үйл явц
үр дүн
Ерөнхийдөө MCS нь бүтээгдэхүүний хувьд аюулгүй юм шиг санагдаж байна. Шалгалтын явцад pentesting багийнхан үйлчлүүлэгчийн VM болон тэдгээрийн өгөгдөлд хандах боломжгүй байсан бөгөөд илрүүлсэн сул талуудыг MCS-ийн баг шуурхай зассан.
Гэхдээ энд хамгаалалт бол тасралтгүй ажил гэдгийг анхаарах нь чухал. Үйлчилгээ нь хөдөлгөөнгүй биш, байнга хувьсан өөрчлөгдөж байдаг. Мөн эмзэг байдалгүйгээр бүтээгдэхүүнийг бүрэн хөгжүүлэх боломжгүй юм. Гэхдээ та тэдгээрийг цаг тухайд нь олж, дахин давтагдах магадлалыг багасгаж чадна.
Одоо MCS-ийн дурдсан бүх эмзэг байдлыг аль хэдийн зассан. Шинэ хүмүүсийн тоог хамгийн бага байлгах, ашиглалтын хугацааг багасгахын тулд платформын баг үүнийг үргэлжлүүлэн хийсээр байна.
- гадны компаниудын аудитыг тогтмол хийх;
- оролцоог дэмжих, хөгжүүлэх;
- аюулгүй байдлын ажилд оролцох. 🙂
Эх сурвалж: www.habr.com