Ревизија безбедности МЦС цлоуд платформе

СкиСхип Дуск би СеерЛигхт

Изградња било које услуге нужно укључује сталан рад на безбедности. Безбедност је континуиран процес који укључује сталну анализу и унапређење безбедности производа, праћење вести о рањивости и још много тога. Укључујући ревизије. Ревизије спроводе и интерни и спољни стручњаци, који могу радикално помоћи у безбедности јер нису уроњени у пројекат и имају отворен ум.

Чланак говори о овом најједноставнијем погледу спољних стручњака који су помогли тиму Маил.ру Цлоуд Солутионс (МЦС) да тестира услугу у облаку и о томе шта су открили. Као „спољну силу“, МЦС је изабрао компанију Дигитал Сецурити, познату по својој високој стручности у круговима информационе безбедности. У овом чланку ћемо анализирати неке занимљиве пропусте пронађене у оквиру екстерне ревизије – тако да избегавате исту грабу када креирате сопствену услугу у облаку.

Описание продукта

Маил.ру Цлоуд Солутионс (МЦС) је платформа за изградњу виртуелне инфраструктуре у облаку. Укључује ИааС, ПааС и тржиште готових слика апликација за програмере. Узимајући у обзир МЦС архитектуру, било је потребно проверити безбедност производа у следећим областима:

• заштита инфраструктуре виртуелизационог окружења: хипервизори, рутирање, заштитни зидови;
• заштита виртуелне инфраструктуре корисника: изолација једне од других, укључујући мрежу, приватне мреже у СДН-у;
• ОпенСтацк и његове отворене компоненте;
• С3 нашег сопственог дизајна;
• ИАМ: пројекти са више закупаца са узором;
• Визија (рачунарска визија): АПИ-ји и рањивости при раду са сликама;
• веб интерфејс и класични веб напади;
• рањивости ПааС компоненти;
• АПИ свих компоненти.

Можда је то све што је битно за даљу историју.

Какав је посао обављен и зашто је био потребан?

Ревизија безбедности има за циљ да идентификује рањивости и грешке у конфигурацији које могу довести до цурења личних података, измене осетљивих информација или поремећаја доступности услуге.

Током рада, који у просеку траје 1-2 месеца, ревизори понављају радње потенцијалних нападача и траже пропусте у клијентским и серверским деловима одабраног сервиса. У контексту ревизије МЦС цлоуд платформе, идентификовани су следећи циљеви:

1. Анализа аутентификације у сервису. Рањивости у овој компоненти би помогле да се одмах уђе на рачуне других људи.
2. Проучавање узора и контроле приступа између различитих налога. За нападача, могућност да добије приступ туђој виртуелној машини је пожељан циљ.
3. Рањивости на страни клијента. КССС/ЦСРФ/ЦРЛФ/итд. Да ли је могуће напасти друге кориснике преко злонамерних веза?
4. Рањивости на страни сервера: РЦЕ и све врсте ињекција (СКЛ/КСКСЕ/ССРФ и тако даље). Пропусте сервера је генерално теже пронаћи, али оне доводе до компромитовања великог броја корисника одједном.
5. Анализа изолације сегмента корисника на нивоу мреже. За нападача, недостатак изолације у великој мери повећава површину напада на друге кориснике.
6. Анализа пословне логике. Да ли је могуће преварити предузећа и бесплатно креирати виртуелне машине?

У овом пројекту се радило по моделу „Граи-бок”: ревизори су комуницирали са услугом уз привилегије обичних корисника, али су делимично поседовали изворни код АПИ-ја и имали су прилику да разјасне детаље са програмерима. Ово је обично најпогоднији, а истовремено и сасвим реалистичан модел рада: интерне информације и даље може да прикупи нападач, само је питање времена.

Пронађене рањивости

Пре него што ревизор почне да шаље различите корисне податке (корисни терет који се користи за извођење напада) на насумична места, неопходно је разумети како ствари функционишу и која функционалност је обезбеђена. Можда се чини да је ово бескорисна вежба, јер на већини проучаваних места неће бити рањивости. Али само разумевање структуре апликације и логике њеног рада омогућиће проналажење најсложенијих вектора напада.

Важно је пронаћи места која делују сумњиво или се на неки начин веома разликују од других. И на овај начин је пронађена прва опасна рањивост.

ИДОР

ИДОР (Инсецуре Дирецт Објецт Референце) рањивости су једна од најчешћих рањивости у пословној логици, која омогућава једном или другом да добије приступ објектима којима приступ заправо није дозвољен. ИДОР рањивости стварају могућност добијања информација о кориснику различитог степена критичности.

Једна од опција ИДОР-а је извођење радњи са системским објектима (корисници, банковни рачуни, артикли у корпи) манипулисањем идентификаторима приступа овим објектима. То доводи до најнепредвидивијих последица. На пример, могућност замене налога пошиљаоца средстава, преко којег их можете украсти од других корисника.

У случају МЦС-а, ревизори су управо открили ИДОР рањивост повезану са небезбедним идентификаторима. У личном налогу корисника, УУИД идентификатори су коришћени за приступ свим објектима, који су, како кажу стручњаци за безбедност, изгледали импресивно несигурни (односно, заштићени од напада грубом силом). Али за одређене ентитете је откривено да се уобичајени предвидљиви бројеви користе за добијање информација о корисницима апликације. Мислим да можете претпоставити да је било могуће променити ИД корисника за један, послати захтев поново и тако добити информације заобилазећи АЦЛ (листу контроле приступа, правила приступа подацима за процесе и кориснике).

Фалсификовање захтева на страни сервера (ССРФ)

Добра ствар код ОпенСоурце производа је што имају огроман број форума са детаљним техничким описима проблема који се јављају и, ако имате среће, описом решења. Али овај новчић има и другу страну: познате рањивости су такође детаљно описане. На пример, постоје дивни описи рањивости на ОпенСтацк форуму [КССС] и [ССРФ], коју из неког разлога нико не жури да поправи.

Уобичајена функционалност апликација је могућност да корисник пошаље линк ка серверу, на који сервер кликне (на пример, да преузме слику са одређеног извора). Ако безбедносни алати не филтрирају саме везе или одговоре које сервер враћа корисницима, такву функционалност могу лако да користе нападачи.

ССРФ рањивости могу у великој мери унапредити развој напада. Нападач може добити:

• ограничен приступ нападнутој локалној мрежи, на пример, само преко одређених сегмената мреже и коришћењем одређеног протокола;
• пун приступ локалној мрежи, ако је могуће спуштање са нивоа апликације на ниво транспорта и, као резултат, потпуно управљање оптерећењем на нивоу апликације;
• приступ читању локалних датотека на серверу (ако је подржана шема филе:///);
• и још много тога.

ССРФ рањивост је одавно позната у ОпенСтацк-у, која је „слепа“ по природи: када контактирате сервер, не добијате одговор од њега, али добијате различите врсте грешака/кашњења, у зависности од резултата захтева . На основу тога можете извршити скенирање портова на хостовима на интерној мрежи, са свим последицама које из тога произилазе које не треба потценити. На пример, производ може имати бацк-оффице АПИ који је доступан само са корпоративне мреже. Уз документацију (не заборавите на инсајдере), нападач може да користи ССРФ за приступ интерним методама. На пример, ако сте некако успели да добијете приближну листу корисних УРЛ-ова, онда помоћу ССРФ-а можете проћи кроз њих и извршити захтев - релативно говорећи, пребацити новац са рачуна на рачун или променити лимите.

Ово није први пут да је ССРФ рањивост откривена у ОпенСтацк-у. У прошлости је било могуће преузети ВМ ИСО слике са директне везе, што је такође довело до сличних последица. Ова функција је сада уклоњена из ОпенСтацк-а. Очигледно, заједница је ово сматрала најједноставнијим и најпоузданијим решењем проблема.

И у ово јавно доступан извештај са услуге ХацкерОне (х1), искоришћавање више не слепог ССРФ-а са могућношћу читања метаподатака инстанце доводи до Роот приступа целој Схопифи инфраструктури.

У МЦС-у, ССРФ рањивости су откривене на два места са сличном функционалношћу, али их је било скоро немогуће искористити због заштитних зидова и других заштита. На овај или онај начин, МЦС тим је ипак решио овај проблем, не чекајући заједницу.

КССС уместо учитавања шкољки

Упркос стотинама написаних студија, из године у годину КССС (цросс-сите сцриптинг) напад је и даље највећи често сусрећу веб рањивост (или напад?).

Отпремање датотека је омиљено место за сваког истраживача безбедности. Често се испоставља да можете учитати произвољну скрипту (асп/јсп/пхп) и извршити наредбе ОС, у терминологији пентестера - „учитавање љуске“. Али популарност таквих рањивости функционише у оба смера: они се памте и против њих се развијају лекови, тако да у последње време вероватноћа „учитавања љуске“ тежи нули.

Нападачки тим (који је представљао Дигитал Сецурити) је имао среће. ОК, у МЦС-у на страни сервера је проверен садржај преузетих датотека, дозвољене су само слике. Али СВГ је такође слика. Како СВГ слике могу бити опасне? Зато што у њих можете да уградите ЈаваСцрипт исечке!

Испоставило се да су преузете датотеке доступне свим корисницима услуге МЦС, што значи да је могућ напад на друге кориснике облака, односно администраторе.

Пример КССС напада на пхисхинг образац за пријаву

Примери експлоатације КССС напада:

• Зашто покушавати да украдете сесију (посебно пошто су сада колачићи само за ХТТП свуда, заштићени од крађе помоћу јс скрипти), ако учитана скрипта може одмах да приступи АПИ-ју ресурса? У овом случају, корисни терет може да користи КСХР захтеве да промени конфигурацију сервера, на пример, да дода нападачев јавни ССХ кључ и добије ССХ приступ серверу.
• Ако ЦСП политика (политика заштите садржаја) забрањује убацивање ЈаваСцрипт-а, нападач може да прође без њега. Користећи чисти ХТМЛ, направите лажни образац за пријаву на сајт и украдите лозинку администратора кроз овај напредни пхисхинг: страница за пхисхинг за корисника завршава на истом УРЛ-у и кориснику је теже да је открије.
• Коначно, нападач може да се договори клијент ДоС — подесите колачиће веће од 4 КБ. Корисник треба да отвори везу само једном, а цео сајт постаје недоступан све док корисник не помисли да посебно очисти претраживач: у огромној већини случајева, веб сервер ће одбити да прихвати таквог клијента.

Погледајмо пример још једног откривеног КССС-а, овог пута са паметнијим експлоатацијом. МЦС услуга вам омогућава да комбинујете подешавања заштитног зида у групе. Назив групе је био место где је КССС откривен. Његова посебност је била у томе што се вектор није активирао одмах, не приликом прегледа листе правила, већ приликом брисања групе:

Односно, испоставило се да је сценарио следећи: нападач креира правило заштитног зида са „учитавањем“ у имену, администратор то примети након неког времена и покреће процес брисања. И ту ради злонамерни ЈС.

Да би МЦС програмери заштитили од КССС-а у отпремљеним СВГ сликама (ако се не могу изоставити), тим за дигиталну безбедност је препоручио:

• Поставите датотеке које су корисници отпремили на посебан домен који нема никакве везе са „колачићима“. Скрипта ће бити извршена у контексту другог домена и неће представљати претњу за МЦС.
• У ХТТП одговору сервера пошаљите заглавље „Диспозиција садржаја: прилог“. Затим ће датотеке бити преузете од стране претраживача и неће бити извршене.

Поред тога, програмерима је сада на располагању много начина да ублаже ризике експлоатације КССС-а:

• користећи ознаку „Само ХТТП“, можете учинити заглавља „колачића“ сесије недоступним злонамерном ЈаваСцрипт-у;
• правилно спроведена ЦСП политика ће отежати нападачу да искористи КССС;
• модерни шаблони као што су Ангулар или Реацт аутоматски дезинфикују корисничке податке пре него што их изнесу у претраживач корисника.

Рањивости двофакторске аутентификације

Да би побољшали безбедност налога, корисницима се увек саветује да омогуће 2ФА (двофакторска аутентикација). Заиста, ово је ефикасан начин да се спречи нападач да добије приступ услузи ако су акредитиви корисника компромитовани.

Али да ли коришћење другог фактора аутентификације увек гарантује сигурност налога? Постоје следећа безбедносна питања у примени 2ФА:

• Бруте форце претрага ОТП кода (једнократни кодови). Упркос једноставности рада, велике компаније наилазе и на грешке као што је недостатак заштите од ОТП грубе силе: Слацк цасе, Фејсбук случај.
• Слаб алгоритам генерисања, на пример могућност предвиђања следећег кода.
• Логичке грешке, као што је могућност да затражите туђи ОТП на свом телефону на овај начин био фром Схопифи.

У случају МЦС-а, 2ФА се имплементира на основу Гоогле Аутхентицатор-а и дуо. Сам протокол је већ временски тестиран, али вреди проверити имплементацију верификације кода на страни апликације.

МЦС 2ФА се користи на неколико места:

• Приликом аутентификације корисника. Постоји заштита од грубе силе: корисник има само неколико покушаја да унесе једнократну лозинку, а затим је унос блокиран неко време. Ово блокира могућност бруталне селекције ОТП-а.
• Приликом генерисања ванмрежних резервних кодова за обављање 2ФА, као и онемогућавања. Овде није имплементирана заштита од грубе силе, што је омогућило да, ако имате лозинку за налог и активну сесију, регенеришете резервне кодове или потпуно онемогућите 2ФА.

С обзиром да су резервни кодови били лоцирани у истом опсегу вредности стрингова као и они које је генерисала ОТП апликација, шанса да се код пронађе за кратко време била је много већа.

Процес одабира ОТП-а за онемогућавање 2ФА помоћу алата „Бурп: Интрудер“.

Резултат

Све у свему, чини се да је МЦС безбедан као производ. Током ревизије, тим за пентестирање није био у могућности да добије приступ клијентским ВМ-овима и њиховим подацима, а МЦС тим је брзо исправио пронађене рањивости.

Али овде је важно напоменути да је безбедност континуирани рад. Услуге нису статичне, оне се стално развијају. И немогуће је потпуно развити производ без рањивости. Али можете их пронаћи на време и минимизирати могућност њиховог поновног појављивања.

Сада су све поменуте рањивости у МЦС-у већ исправљене. А да би се број нових свео на минимум и смањио њихов животни век, тим платформе наставља да ради ово:

• редовно спроводи ревизије од стране екстерних компанија;
• подржавају и развијају учешће у програму Маил.ру Гроуп Буг Боунти;
• бавити се обезбеђењем. 🙂

Извор: ввв.хабр.цом