SeerLight tomonidan
Har qanday xizmatni qurish, albatta, xavfsizlik bo'yicha doimiy ishlarni o'z ichiga oladi. Xavfsizlik uzluksiz jarayon bo'lib, mahsulot xavfsizligini doimiy tahlil qilish va takomillashtirish, zaifliklar haqidagi yangiliklarni kuzatish va boshqa ko'p narsalarni o'z ichiga oladi. Shu jumladan audit. Auditni o'z ichiga ham, tashqi ekspertlar ham amalga oshiradilar, ular xavfsizlikni ta'minlashda tubdan yordam berishi mumkin, chunki ular loyihaga sho'ng'ilmagan va ochiq fikrga ega.
Maqolada Mail.ru Cloud Solutions (MCS) jamoasiga bulut xizmatini sinovdan o'tkazishda yordam bergan tashqi ekspertlarning eng oddiy ko'rinishi va ular topgan narsalar haqida. "Tashqi kuch" sifatida MCS axborot xavfsizligi sohasida o'zining yuqori tajribasi bilan mashhur Digital Security kompaniyasini tanladi. Va ushbu maqolada biz tashqi auditning bir qismi sifatida topilgan ba'zi qiziqarli zaifliklarni tahlil qilamiz - shunda siz o'zingizning bulutli xizmatingizni yaratganingizda bir xil rakedan qochishingiz mumkin.
Mahsulot ta'rifi
bulutda virtual infratuzilmani yaratish uchun platformadir. U IaaS, PaaS va ishlab chiquvchilar uchun tayyor ilovalar tasvirlari bozorini o'z ichiga oladi. MCS arxitekturasini hisobga olgan holda, mahsulotning xavfsizligini quyidagi sohalarda tekshirish kerak edi:
- virtualizatsiya muhiti infratuzilmasini himoya qilish: gipervisorlar, marshrutlash, xavfsizlik devorlari;
- mijozlarning virtual infratuzilmasini himoya qilish: bir-biridan, shu jumladan tarmoqdan, SDN-dagi xususiy tarmoqlardan izolyatsiya qilish;
- OpenStack va uning ochiq komponentlari;
- O'z dizaynimizdagi S3;
- IAM: namunali ko'p ijarachi loyihalari;
- Vizyon (kompyuterni ko'rish): API va tasvirlar bilan ishlashda zaifliklar;
- veb-interfeys va klassik veb-hujumlar;
- PaaS komponentlarining zaifliklari;
- Barcha komponentlarning API.
Ehtimol, bu keyingi tarix uchun zarur bo'lgan narsadir.
Qanday ish olib borildi va nima uchun kerak edi?
Xavfsizlik auditi shaxsiy ma'lumotlarning sizib chiqishiga, maxfiy ma'lumotlarni o'zgartirishga yoki xizmat mavjudligini buzishga olib kelishi mumkin bo'lgan zaifliklar va konfiguratsiya xatolarini aniqlashga qaratilgan.
O'rtacha 1-2 oy davom etadigan ish davomida auditorlar potentsial hujumchilarning harakatlarini takrorlaydi va tanlangan xizmatning mijoz va server qismlarida zaifliklarni qidiradi. MCS bulutli platformasi auditi doirasida quyidagi maqsadlar aniqlandi:
- Xizmatda autentifikatsiyani tahlil qilish. Ushbu komponentdagi zaifliklar darhol boshqa odamlarning hisoblariga kirishga yordam beradi.
- Rol modelini o'rganish va turli hisoblar o'rtasida kirishni boshqarish. Tajovuzkor uchun boshqa birovning virtual mashinasiga kirish imkoniyati orzu qilingan maqsaddir.
- Mijoz tarafidagi zaifliklar. XSS/CSRF/CRLF/va boshqalar. Zararli havolalar orqali boshqa foydalanuvchilarga hujum qilish mumkinmi?
- Server tomonidagi zaifliklar: RCE va barcha turdagi inyeksiyalar (SQL/XXE/SSRF va boshqalar). Server zaifliklarini topish odatda qiyinroq, lekin ular bir vaqtning o'zida ko'plab foydalanuvchilarning murosaga olib keladi.
- Tarmoq darajasida foydalanuvchi segmentini izolyatsiyasini tahlil qilish. Tajovuzkor uchun izolyatsiyaning yo'qligi boshqa foydalanuvchilarga qarshi hujum maydonini sezilarli darajada oshiradi.
- Biznes mantiqiy tahlili. Korxonalarni aldash va virtual mashinalarni bepul yaratish mumkinmi?
Ushbu loyihada ish "Grey-box" modeli bo'yicha amalga oshirildi: auditorlar xizmat bilan oddiy foydalanuvchilarning imtiyozlari bilan o'zaro aloqada bo'lishdi, ammo qisman API manba kodiga ega bo'lishdi va ishlab chiquvchilar bilan tafsilotlarni aniqlashtirish imkoniyatiga ega bo'lishdi. Bu, odatda, eng qulay va ayni paytda juda real ish modelidir: ichki ma'lumot hali ham tajovuzkor tomonidan to'planishi mumkin, bu faqat vaqt masalasidir.
Zaifliklar topildi
Auditor turli xil foydali yuklarni (hujumni amalga oshirish uchun ishlatiladigan foydali yuk) tasodifiy joylarga yuborishni boshlashdan oldin, narsalar qanday ishlashini va qanday funksionallik bilan ta'minlanganligini tushunish kerak. Bu befoyda mashq bo'lib tuyulishi mumkin, chunki ko'pchilik o'rganilgan joylarda zaifliklar bo'lmaydi. Ammo faqat dastur tuzilishini va uning ishlash mantiqini tushunish eng murakkab hujum vektorlarini topishga imkon beradi.
Shubhali ko'rinadigan yoki qaysidir ma'noda boshqalardan juda farq qiladigan joylarni topish muhimdir. Va birinchi xavfli zaiflik shu tarzda topildi.
IDOR
IDOR (Insecure Direct Object Reference) zaifliklari biznes mantiqidagi eng keng tarqalgan zaifliklardan biri bo'lib, u yoki buning kirishiga ruxsat etilmagan ob'ektlarga kirish imkonini beradi. IDOR zaifliklari foydalanuvchi haqida turli darajadagi tanqidiy ma'lumotlarni olish imkoniyatini yaratadi.
IDOR opsiyalaridan biri tizim ob'ektlari (foydalanuvchilar, bank hisoblari, xarid qilish savatidagi narsalar) bilan ushbu ob'ektlarga kirish identifikatorlarini manipulyatsiya qilish orqali amallarni bajarishdir. Bu eng oldindan aytib bo'lmaydigan oqibatlarga olib keladi. Masalan, pul jo'natuvchining hisobini almashtirish imkoniyati, bu orqali siz ularni boshqa foydalanuvchilardan o'g'irlashingiz mumkin.
MCS misolida, auditorlar endigina xavfsiz bo'lmagan identifikatorlar bilan bog'liq IDOR zaifligini aniqladilar. Foydalanuvchining shaxsiy kabinetida UUID identifikatorlari har qanday ob'ektlarga kirish uchun ishlatilgan, ular xavfsizlik bo'yicha mutaxassislar ta'kidlaganidek, ta'sirchan darajada xavfli bo'lib tuyulgan (ya'ni qo'pol kuch hujumlaridan himoyalangan). Ammo ba'zi ob'ektlar uchun dastur foydalanuvchilari haqida ma'lumot olish uchun muntazam bashorat qilinadigan raqamlardan foydalanilishi aniqlandi. O'ylaymanki, foydalanuvchi identifikatorini bittaga o'zgartirish, so'rovni qayta yuborish va shu tariqa ACLni chetlab o'tib ma'lumot olish mumkin edi (kirishni boshqarish ro'yxati, jarayonlar va foydalanuvchilar uchun ma'lumotlarga kirish qoidalari).
Server tomoni so'rovini soxtalashtirish (SSRF)
OpenSource mahsulotlarining yaxshi tomoni shundaki, ularda yuzaga keladigan muammolarning batafsil texnik tavsiflari va agar omadingiz bo'lsa, echimning tavsifi mavjud bo'lgan juda ko'p forumlar mavjud. Ammo bu tanganing boshqa tomoni bor: ma'lum zaifliklar ham batafsil tavsiflangan. Misol uchun, OpenStack forumida zaifliklarning ajoyib tavsiflari mavjud и , negadir hech kim tuzatishga shoshilmayapti.
Ilovalarning umumiy funksionalligi foydalanuvchining server bosgan serverga havolani yuborish qobiliyatidir (masalan, belgilangan manbadan rasmni yuklab olish). Agar xavfsizlik vositalari havolalarni yoki serverdan foydalanuvchilarga qaytarilgan javoblarni filtrlamasa, bunday funksiyadan tajovuzkorlar osongina foydalanishlari mumkin.
SSRF zaifliklari hujumning rivojlanishini sezilarli darajada oshirishi mumkin. Hujumchi quyidagilarni olishi mumkin:
- hujum qilingan mahalliy tarmoqqa cheklangan kirish, masalan, faqat ma'lum tarmoq segmentlari orqali va ma'lum bir protokol yordamida;
- mahalliy tarmoqqa to'liq kirish, agar dastur darajasidan transport darajasiga tushirish mumkin bo'lsa va natijada dastur darajasida yukni to'liq boshqarish;
- serverdagi mahalliy fayllarni o'qishga kirish (agar file:/// sxemasi qo'llab-quvvatlansa);
- va boshqalar.
SSRF zaifligi OpenStack-da uzoq vaqtdan beri ma'lum bo'lib, tabiatan "ko'r": server bilan bog'langaningizda siz undan javob olmaysiz, ammo so'rov natijasiga qarab siz turli xil xatolar/kechikishlarni olasiz. . Bunga asoslanib, siz ichki tarmoqdagi xostlarda portni skanerlashni amalga oshirishingiz mumkin, buning natijasida yuzaga keladigan barcha oqibatlarga e'tibor bermaslik kerak. Misol uchun, mahsulot faqat korporativ tarmoqdan foydalanish mumkin bo'lgan back-ofis API-ga ega bo'lishi mumkin. Hujjatlar bilan (insayderlar haqida unutmang), tajovuzkor ichki usullarga kirish uchun SSRF dan foydalanishi mumkin. Misol uchun, agar siz qandaydir tarzda foydali URL-manzillarning taxminiy ro'yxatini olishga muvaffaq bo'lsangiz, SSRF-dan foydalanib, siz ular orqali o'tishingiz va so'rovni bajarishingiz mumkin - nisbatan aytganda, hisobdan hisob raqamiga pul o'tkazish yoki cheklovlarni o'zgartirish.
Bu OpenStack-da SSRF zaifligi birinchi marta aniqlangani emas. Ilgari, VM ISO tasvirlarini to'g'ridan-to'g'ri havoladan yuklab olish mumkin edi, bu ham shunga o'xshash oqibatlarga olib keldi. Bu xususiyat endi OpenStack'dan olib tashlandi. Aftidan, jamiyat buni muammoning eng oddiy va ishonchli yechimi deb hisoblagan.
Va ichkarida HackerOne xizmatidan (h1) ommaga ochiq hisobot, misol metamaʼlumotlarini oʻqish qobiliyatiga ega endi koʻr boʻlmagan SSRF-dan foydalanish Shopify infratuzilmasiga Root-dan foydalanish imkonini beradi.
MCS-da SSRF zaifliklari o'xshash funksiyalarga ega bo'lgan ikkita joyda topilgan, ammo xavfsizlik devorlari va boshqa himoya vositalari tufayli ulardan foydalanish deyarli mumkin emas edi. Qanday bo'lmasin, MCS jamoasi hamjamiyatni kutmasdan, baribir bu muammoni hal qildi.
Chig'anoqlarni yuklash o'rniga XSS
Yozilgan yuzlab tadqiqotlarga qaramay, yildan-yilga XSS (saytlararo skript) hujumi hali ham eng ko'p veb zaifligi (yoki ?).
Fayllarni yuklash har qanday xavfsizlik tadqiqotchisi uchun sevimli joy. Ko'pincha siz ixtiyoriy skriptni (asp/jsp/php) yuklashingiz va OS buyruqlarini bajarishingiz mumkin, pentesters terminologiyasida - "yuklash qobig'i". Ammo bunday zaifliklarning mashhurligi har ikki yo'nalishda ham ishlaydi: ular esga olinadi va ularga qarshi vositalar ishlab chiqiladi, shuning uchun yaqinda "qobiqni yuklash" ehtimoli nolga tushadi.
Hujum qilayotgan jamoaga (Digital Security vakili) omad kulib boqdi. OK, server tomonidagi MCS-da yuklab olingan fayllarning mazmuni tekshirildi, faqat rasmlarga ruxsat berildi. Ammo SVG ham rasmdir. SVG tasvirlari qanday xavfli bo'lishi mumkin? Chunki siz ularga JavaScript snippetlarini joylashtirishingiz mumkin!
Ma'lum bo'lishicha, yuklab olingan fayllar MCS xizmatining barcha foydalanuvchilari uchun mavjud, ya'ni boshqa bulut foydalanuvchilariga, ya'ni administratorlarga hujum qilish mumkin.
Fishing login formasiga XSS hujumiga misol
XSS hujumidan foydalanishga misollar:
- Nega seansni o'g'irlashga harakat qilish kerak (ayniqsa, hozir JS skriptlari yordamida o'g'irlikdan himoyalangan HTTP-faqat cookie fayllari mavjud), agar yuklangan skript darhol API resursiga kira olsa? Bunday holda, foydali yuk server konfiguratsiyasini o'zgartirish uchun XHR so'rovlaridan foydalanishi mumkin, masalan, tajovuzkorning umumiy SSH kalitini qo'shish va serverga SSH ruxsatini olish.
- Agar CSP siyosati (kontentni himoya qilish siyosati) JavaScript-ni in'ektsiya qilishni taqiqlasa, tajovuzkor ularsiz ham o'tib ketishi mumkin. Sof HTML-dan foydalanib, sayt uchun soxta login formasini yarating va ushbu ilg'or fishing orqali administrator parolini o'g'irlang: foydalanuvchi uchun fishing sahifasi bir xil URL manzilida tugaydi va foydalanuvchi uni aniqlashi qiyinroq.
- Nihoyat, hujumchi tartibga keltirishi mumkin — 4 KB dan katta cookie-fayllarni o'rnating. Foydalanuvchi faqat bir marta havolani ochishi kerak va foydalanuvchi brauzerni maxsus tozalashni o'ylaguncha butun saytga kirish imkoni bo'lmaydi: aksariyat hollarda veb-server bunday mijozni qabul qilishdan bosh tortadi.
Keling, boshqa aniqlangan XSS misolini ko'rib chiqaylik, bu safar yanada oqilona ekspluatatsiya bilan. MCS xizmati xavfsizlik devori sozlamalarini guruhlarga birlashtirish imkonini beradi. Guruh nomi XSS aniqlangan joy edi. Uning o'ziga xosligi shundaki, vektor qoidalar ro'yxatini ko'rishda emas, balki guruhni o'chirishda darhol ishga tushmadi:
Ya'ni, stsenariy quyidagicha bo'lib chiqdi: tajovuzkor nomida "yuklash" bilan xavfsizlik devori qoidasini yaratadi, ma'mur uni birozdan keyin sezadi va o'chirish jarayonini boshlaydi. Va bu erda zararli JS ishlaydi.
MCS ishlab chiquvchilari uchun yuklab olingan SVG tasvirlarida XSS dan himoyalanish uchun (agar ularni tashlab bo'lmasa), Digital Security jamoasi tavsiya qiladi:
- Foydalanuvchilar tomonidan yuklangan fayllarni "cookie" ga hech qanday aloqasi bo'lmagan alohida domenga joylashtiring. Skript boshqa domen kontekstida bajariladi va MCS uchun xavf tug'dirmaydi.
- Serverning HTTP javobida "Content-disposition: ilova" sarlavhasini yuboring. Keyin fayllar brauzer tomonidan yuklab olinadi va bajarilmaydi.
Bundan tashqari, hozirda ishlab chiquvchilar uchun XSS-dan foydalanish xavfini kamaytirishning ko'plab usullari mavjud:
- "Faqat HTTP" bayrog'idan foydalanib, "Cookie" seansining sarlavhalarini zararli JavaScript-ga kirish imkoni bo'lmagan qilib qo'yishingiz mumkin;
- tajovuzkor XSS-dan foydalanishni ancha qiyinlashtiradi;
- Angular yoki React kabi zamonaviy shablon dvigatellari foydalanuvchi ma'lumotlarini foydalanuvchi brauzeriga chiqarishdan oldin avtomatik ravishda tozalaydi.
Ikki faktorli autentifikatsiyadagi zaifliklar
Hisob xavfsizligini yaxshilash uchun foydalanuvchilarga har doim 2FA (ikki faktorli autentifikatsiya) ni yoqish tavsiya etiladi. Haqiqatan ham, agar foydalanuvchining hisob ma'lumotlari buzilgan bo'lsa, bu tajovuzkorning xizmatga kirishini oldini olishning samarali usulidir.
Ammo ikkinchi autentifikatsiya faktoridan foydalanish har doim hisob xavfsizligini kafolatlaydimi? 2FAni amalga oshirishda quyidagi xavfsizlik muammolari mavjud:
- OTP kodini shafqatsiz qidiruv (bir martalik kodlar). Amaliyotning soddaligiga qaramay, yirik kompaniyalar tomonidan OTP qo'pol kuchdan himoya etishmasligi kabi xatolar ham uchraydi: , .
- Zaif avlod algoritmi, masalan, keyingi kodni bashorat qilish qobiliyati.
- Mantiqiy xatolar, masalan, telefoningizda boshqa birovning OTP-ni so'rash qobiliyati Shopify'dan.
MCS misolida 2FA Google Authenticator va asosida amalga oshiriladi . Protokolning o'zi allaqachon vaqt sinovidan o'tgan, ammo dastur tomonida kodni tekshirishni amalga oshirishni tekshirishga arziydi.
MCS 2FA bir necha joylarda qo'llaniladi:
- Foydalanuvchini autentifikatsiya qilishda. Shafqatsiz kuchdan himoya mavjud: foydalanuvchi faqat bir martalik parolni kiritish uchun bir nechta urinishlarga ega, keyin kirish bir muddat bloklanadi. Bu OTP ni qo'pol kuch tanlash imkoniyatini bloklaydi.
- 2FA ni bajarish uchun oflayn zaxira kodlarini yaratishda, shuningdek uni o'chirishda. Bu erda hech qanday qo'pol kuch himoyasi amalga oshirilmadi, bu sizning hisobingiz uchun parolingiz va faol seansingiz bo'lsa, zaxira kodlarini qayta tiklash yoki 2FA-ni butunlay o'chirib qo'yish imkonini berdi.
Zaxira kodlari OTP ilovasi tomonidan yaratilgan qator qiymatlari oralig'ida joylashganligini hisobga olsak, kodni qisqa vaqt ichida topish imkoniyati ancha yuqori edi.
"Burp: Intruder" vositasi yordamida 2FAni o'chirish uchun OTPni tanlash jarayoni
natija
Umuman olganda, MCS mahsulot sifatida xavfsiz ko'rinadi. Tekshiruv davomida pentesting guruhi mijozning VM-lariga va ularning ma'lumotlariga kirish imkoniga ega bo'lmadi va topilgan zaifliklar MCS jamoasi tomonidan tezda tuzatildi.
Ammo bu erda xavfsizlik uzluksiz ish ekanligini ta'kidlash muhimdir. Xizmatlar statik emas, ular doimo rivojlanib boradi. Va zaifliklarsiz mahsulotni to'liq ishlab chiqish mumkin emas. Ammo siz ularni o'z vaqtida topishingiz va ularning takrorlanish ehtimolini kamaytirishingiz mumkin.
Endi MCS-dagi barcha qayd etilgan zaifliklar allaqachon tuzatilgan. Va yangilar sonini minimal darajada ushlab turish va ularning ishlash muddatini qisqartirish uchun platforma jamoasi buni davom ettirmoqda:
- tashqi kompaniyalar tomonidan muntazam ravishda audit o'tkazish;
- ishtirokini qo‘llab-quvvatlash va rivojlantirish;
- xavfsizlik bilan shug'ullanish. 🙂
Manba: www.habr.com