SeerLight арқылы
Кез келген қызметті құру міндетті түрде қауіпсіздік бойынша тұрақты жұмысты қамтиды. Қауіпсіздік - өнімнің қауіпсіздігін тұрақты талдау мен жақсартуды, осалдықтар туралы жаңалықтарды бақылауды және т.б. қамтитын үздіксіз процесс. Аудиттерді қоса алғанда. Аудиттерді кәсіпорын ішінде де, сыртқы сарапшылар да жүргізеді, олар қауіпсіздікті қамтамасыз етуге түбегейлі көмектесе алады, өйткені олар жобаға енбеген және ашық пікірге ие.
Мақалада Mail.ru Cloud Solutions (MCS) тобына бұлттық қызметті сынауға көмектескен сыртқы сарапшылардың ең қарапайым көзқарасы және олар не тапқаны туралы. «Сыртқы күш» ретінде MCS ақпараттық қауіпсіздік саласындағы жоғары тәжірибесімен танымал Digital Security компаниясын таңдады. Және бұл мақалада біз сыртқы аудиттің бөлігі ретінде табылған кейбір қызықты осалдықтарды талдаймыз - осылайша сіз өзіңіздің жеке бұлттық қызметті жасаған кезде бірдей рейкті болдырмассыз.
Өнім сипаттамасы
бұлтта виртуалды инфрақұрылым құруға арналған платформа болып табылады. Ол IaaS, PaaS және әзірлеушілерге арналған дайын қолданба кескіндерінің нарығын қамтиды. MCS архитектурасын ескере отырып, өнімнің қауіпсіздігін келесі бағыттар бойынша тексеру қажет болды:
- виртуалдандыру ортасының инфрақұрылымын қорғау: гипервизорлар, маршруттау, желіаралық қалқандар;
- тұтынушылардың виртуалды инфрақұрылымын қорғау: бір-бірінен, соның ішінде желіден, SDN-дегі жеке желілерден оқшаулау;
- OpenStack және оның ашық компоненттері;
- S3 жеке дизайн;
- IAM: үлгі алатын көп пәтерлі жобалар;
- Көру (компьютерлік көру): API интерфейстері және кескіндермен жұмыс істеу кезіндегі осалдықтар;
- веб-интерфейс және классикалық веб-шабуылдар;
- PaaS құрамдастарының осалдықтары;
- барлық компоненттердің API интерфейсі.
Бәлкім, бұл кейінгі тарих үшін қажет нәрсенің бәрі.
Қандай жұмыс жүргізілді және ол не үшін қажет болды?
Қауіпсіздік аудиті жеке деректердің ағып кетуіне, құпия ақпаратты өзгертуге немесе қызметтің қолжетімділігін бұзуға әкелуі мүмкін осалдықтарды және конфигурация қателерін анықтауға бағытталған.
Орташа алғанда 1-2 айға созылатын жұмыс барысында аудиторлар ықтимал шабуылдаушылардың әрекеттерін қайталайды және таңдалған қызметтің клиенттік және серверлік бөліктеріндегі осалдықтарды іздейді. MCS бұлттық платформасының аудиті аясында келесі мақсаттар анықталды:
- Сервисте аутентификацияны талдау. Бұл құрамдастағы осалдықтар басқа адамдардың есептік жазбаларына бірден енуге көмектеседі.
- Үлгіні зерттеу және әртүрлі тіркелгілер арасындағы қатынасты басқару. Шабуылдаушы үшін басқа біреудің виртуалды машинасына қол жеткізу мүмкіндігі қалаулы мақсат болып табылады.
- Клиенттік осалдықтар. XSS/CSRF/CRLF/т.б. Зиянды сілтемелер арқылы басқа пайдаланушыларға шабуыл жасау мүмкін бе?
- Сервер жағындағы осалдықтар: RCE және инъекциялардың барлық түрлері (SQL/XXE/SSRF және т.б.). Сервердің осалдықтарын табу әдетте қиынырақ, бірақ олар бірден көптеген пайдаланушылардың ымыраға келуіне әкеледі.
- Желі деңгейінде пайдаланушы сегментінің оқшаулануын талдау. Шабуылдаушы үшін оқшаулаудың жоқтығы басқа пайдаланушыларға қарсы шабуылдың бетін айтарлықтай арттырады.
- Іскерлік логикалық талдау. Бизнесті алдап, виртуалды машиналарды тегін жасауға бола ма?
Бұл жобада жұмыс «Gray-box» моделі бойынша жүргізілді: аудиторлар қызметпен қарапайым пайдаланушылардың артықшылықтарымен өзара әрекеттесті, бірақ ішінара API бастапқы кодын иеленді және әзірлеушілермен егжей-тегжейлерді нақтылау мүмкіндігіне ие болды. Бұл әдетте ең ыңғайлы және сонымен бірге нақты жұмыс үлгісі: ішкі ақпаратты әлі де шабуылдаушы жинай алады, бұл тек уақыт мәселесі.
Осалдықтар табылды
Аудитор әртүрлі пайдалы жүктемелерді (шабуыл жасау үшін пайдаланылатын пайдалы жүктеме) кездейсоқ орындарға жіберуді бастамас бұрын, заттардың қалай жұмыс істейтінін және қандай функционалдық қамтамасыз етілгенін түсіну керек. Бұл пайдасыз жаттығу болып көрінуі мүмкін, өйткені зерттелген орындардың көпшілігінде осалдықтар болмайды. Бірақ қосымшаның құрылымын және оның жұмысының логикасын түсіну ғана ең күрделі шабуыл векторларын табуға мүмкіндік береді.
Күдікті болып көрінетін немесе қандай да бір жолмен басқалардан өте ерекшеленетін орындарды табу маңызды. Ал бірінші қауіпті осалдық осылайша табылды.
IDOR
IDOR (қауіпсіз тікелей нысан сілтемесі) осалдықтары іскерлік логикадағы ең кең тараған осалдықтардың бірі болып табылады, ол қол жеткізуге нақты рұқсат етілмеген нысандарға қол жеткізуге мүмкіндік береді. IDOR осалдықтары әртүрлі сыни дәрежедегі пайдаланушы туралы ақпаратты алу мүмкіндігін тудырады.
IDOR опцияларының бірі жүйе объектілерімен (пайдаланушылар, банктік шоттар, сатып алу себетіндегі элементтер) осы нысандарға кіру идентификаторларын өңдеу арқылы әрекеттерді орындау болып табылады. Бұл ең күтпеген салдарға әкеледі. Мысалы, ақша жіберушінің шотын ауыстыру мүмкіндігі, ол арқылы сіз оларды басқа пайдаланушылардан ұрлай аласыз.
MCS жағдайында аудиторлар қауіпсіз емес идентификаторлармен байланысты IDOR осалдығын анықтады. Пайдаланушының жеке кабинетінде UUID идентификаторлары кез келген нысандарға қол жеткізу үшін пайдаланылды, бұл қауіпсіздік сарапшылары айтқандай, өте қауіпті (яғни, қатыгездік шабуылдарынан қорғалған). Бірақ кейбір субъектілер үшін қосымшаны пайдаланушылар туралы ақпаратты алу үшін тұрақты болжамды сандар қолданылатыны анықталды. Менің ойымша, сіз пайдаланушы идентификаторын біреуге өзгертуге, сұрауды қайта жіберуге және осылайша ACL-ді айналып өтіп ақпаратты алуға болатынын болжауға болады (қолжетімділікті басқару тізімі, процестер мен пайдаланушылар үшін деректерге қол жеткізу ережелері).
Сервер тарапынан сұрауды жалған жасау (SSRF)
OpenSource өнімдерінің жақсы жағы - оларда туындайтын мәселелердің егжей-тегжейлі техникалық сипаттамалары және, егер сәттілік болса, шешімнің сипаттамасы бар көптеген форумдар бар. Бірақ бұл монетаның екінші жағы бар: белгілі осалдықтар да егжей-тегжейлі сипатталған. Мысалы, OpenStack форумында осалдықтардың тамаша сипаттамалары бар и , оны қандай да бір себептермен ешкім жөндеуге асығар емес.
Қолданбалардың жалпы функционалдығы пайдаланушының сервер басқанатын серверге сілтеме жіберу мүмкіндігі болып табылады (мысалы, көрсетілген көзден суретті жүктеп алу). Қауіпсіздік құралдары сілтемелердің өзін немесе серверден пайдаланушыларға қайтарылған жауаптарды сүзбесе, мұндай функцияны шабуылдаушылар оңай пайдалана алады.
SSRF осалдықтары шабуылдың дамуын айтарлықтай ілгерілетуі мүмкін. Шабуылдаушы мыналарды ала алады:
- шабуылға ұшыраған жергілікті желіге шектеулі қол жеткізу, мысалы, белгілі бір желі сегменттері арқылы және белгілі бір хаттаманы пайдалану арқылы;
- жергілікті желіге толық қолжетімділік, егер қолданба деңгейінен көлік деңгейіне дейін төмендету мүмкін болса және соның нәтижесінде қолданба деңгейінде толық жүктемені басқару;
- сервердегі жергілікті файлдарды оқуға рұқсат (егер file:/// схемасына қолдау көрсетілсе);
- и многое другое.
SSRF осалдығы OpenStack-те бұрыннан белгілі, ол табиғаты бойынша «соқыр»: серверге хабарласқанда сіз одан жауап алмайсыз, бірақ сұрау нәтижесіне байланысты әртүрлі қателер/кідірістерді аласыз. . Осыған сүйене отырып, сіз ішкі желідегі хосттарда портты сканерлеуді орындай аласыз, одан кейінгі барлық салдарларды елемеуге болмайды. Мысалы, өнімде тек корпоративтік желіден қол жеткізуге болатын бэк-офис API болуы мүмкін. Құжаттамамен (инсайдерлер туралы ұмытпаңыз) шабуылдаушы ішкі әдістерге қол жеткізу үшін SSRF пайдалана алады. Мысалы, егер сіз қандай да бір жолмен пайдалы URL мекенжайларының шамамен тізімін ала алсаңыз, онда SSRF көмегімен сіз олар арқылы өтіп, сұрауды орындай аласыз - салыстырмалы түрде, шоттан шотқа ақша аударуға немесе шектеулерді өзгертуге болады.
Бұл OpenStack жүйесінде SSRF осалдығы бірінші рет табылған жоқ. Бұрын VM ISO кескіндерін тікелей сілтемеден жүктеп алуға болатын еді, бұл да осындай салдарға әкелді. Бұл мүмкіндік енді OpenStack-тен жойылды. Қауымдастық мұны мәселенің ең қарапайым және сенімді шешімі деп санаса керек.
Және HackerOne қызметінің (h1) жалпыға қолжетімді есебі, даналық метадеректерді оқу мүмкіндігі бар соқыр емес SSRF пайдалану бүкіл Shopify инфрақұрылымына түбірлік қатынасқа әкеледі.
MCS жүйесінде SSRF осалдықтары ұқсас функционалдығы бар екі жерде табылды, бірақ желіаралық қалқандар мен басқа қорғау құралдарының арқасында оларды пайдалану мүмкін емес еді. Қалай болғанда да, MCS командасы бұл мәселені қауымдастықты күтпей-ақ шешті.
Қабықшаларды жүктеудің орнына XSS
Жазылған жүздеген зерттеулерге қарамастан, жыл сайын XSS (сайтаралық сценарий) шабуылы әлі де ең көп веб осалдығы (немесе ?).
Файлды жүктеп салу - кез келген қауіпсіздік зерттеушісі үшін сүйікті орын. Көбінесе сіз еркін сценарийді (asp/jsp/php) жүктеп, ОЖ пәрмендерін орындауға болады, пентестер терминологиясында - «жүктеу қабығы». Бірақ мұндай осалдықтардың танымалдылығы екі бағытта да жұмыс істейді: олар есте сақталады және оларға қарсы құралдар әзірленеді, сондықтан жақында «қабықты жүктеу» ықтималдығы нөлге тең болады.
Шабуылдаушы команданың (Digital Security ұсынған) жолы болды. Жарайды, сервер жағындағы MCS-те жүктелген файлдардың мазмұны тексерілді, тек кескіндерге рұқсат етілді. Бірақ SVG - бұл сурет. SVG кескіндері қалай қауіпті болуы мүмкін? Өйткені сіз оларға JavaScript үзінділерін ендіре аласыз!
Жүктелген файлдар MCS сервисінің барлық пайдаланушыларына қолжетімді екені белгілі болды, яғни бұлтты басқа пайдаланушыларға, атап айтқанда әкімшілерге шабуыл жасауға болады.
Фишингтік кіру пішініне XSS шабуылының мысалы
XSS шабуылдарын пайдалану мысалдары:
- Неліктен сеансты ұрлауға тырысу керек (әсіресе қазір тек HTTP-cookie файлдары барлық жерде, JS сценарийлері арқылы ұрланудан қорғалған), егер жүктелген сценарий API ресурсына бірден қол жеткізе алса? Бұл жағдайда пайдалы жүктеме сервер конфигурациясын өзгерту үшін XHR сұрауларын пайдалана алады, мысалы, шабуылдаушының жалпы SSH кілтін қосып, серверге SSH рұқсатын алады.
- Егер CSP саясаты (мазмұнды қорғау саясаты) JavaScript енгізуге тыйым салса, шабуылдаушы онсыз да жеңе алады. Таза HTML арқылы сайтқа жалған кіру пішінін жасаңыз және осы жетілдірілген фишинг арқылы әкімшінің құпия сөзін ұрлаңыз: пайдаланушыға арналған фишинг беті бір URL мекенжайында аяқталады және пайдаланушы оны анықтау қиынырақ.
- Ақырында, шабуылдаушы ұйымдастыра алады — 4 КБ-тан үлкен cookie файлдарын орнатыңыз. Пайдаланушы тек бір рет сілтемені ашуы керек және пайдаланушы браузерді арнайы тазалауды ойламайынша, бүкіл сайтқа қол жетімсіз болады: көп жағдайда веб-сервер мұндай клиентті қабылдаудан бас тартады.
Басқа анықталған XSS мысалын қарастырайық, бұл жолы ақылды эксплуатация. MCS қызметі желіаралық қалқан параметрлерін топтарға біріктіруге мүмкіндік береді. Топ атауы XSS анықталған жерде болды. Оның ерекшелігі вектор ережелер тізімін қарау кезінде емес, топты жою кезінде бірден іске қосылмады:
Яғни, сценарий келесідей болды: шабуылдаушы атауында «жүктеме» бар брандмауэр ережесін жасайды, әкімші оны біраз уақыттан кейін байқап, жою процесін бастайды. Міне, зиянды JS жұмыс істейді.
MCS әзірлеушілеріне жүктелген SVG кескіндеріндегі XSS-тен қорғау үшін (егер олардан бас тарту мүмкін болмаса), Digital Security командасы мыналарды ұсынады:
- Пайдаланушылар жүктеп салған файлдарды «cookie файлдарына» еш қатысы жоқ бөлек доменге орналастырыңыз. Сценарий басқа домен контекстінде орындалады және MCS үшін қауіп төндірмейді.
- Сервердің HTTP жауабында «Content-disposition: тіркеме» тақырыбын жіберіңіз. Содан кейін файлдар браузер арқылы жүктеледі және орындалмайды.
Сонымен қатар, қазір әзірлеушілерге XSS пайдалану қаупін азайтудың көптеген жолдары бар:
- «Тек HTTP» жалаушасын пайдаланып, «Cookie файлдары» сеансының тақырыптарын зиянды 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 өнім ретінде қауіпсіз болып көрінеді. Аудит барысында пентестинг тобы клиенттік виртуалды құрылғыларға және олардың деректеріне қол жеткізе алмады және табылған осалдықтарды MCS командасы тез түзетеді.
Бірақ бұл жерде қауіпсіздіктің үздіксіз жұмыс екенін атап өткен жөн. Қызметтер тұрақты емес, олар үнемі дамып отырады. Ал осалдықтарсыз өнімді толығымен әзірлеу мүмкін емес. Бірақ сіз оларды уақытында тауып, олардың қайталану мүмкіндігін азайта аласыз.
Енді MCS-тегі барлық аталған осалдықтар түзетілді. Жаңалардың санын барынша азайту және олардың қызмет ету мерзімін қысқарту үшін платформа командасы мұны жалғастыруда:
- тұрақты түрде сыртқы компаниялар аудитін жүргізу;
- қатысуын қолдау және дамыту;
- қауіпсіздікпен айналысу. 🙂
Ақпарат көзі: www.habr.com