🥇Одит на безопасността на облачната платформа MCS

SkyShip Dusk от SeerLight

Създаването на всеки сервис задължително включва постоянни усилия за осигуряване на сигурност. Сигурността е непрекъснат процес, който включва постоянно анализиране и усъвършенстване на защитата на продукта, проследяване на новините за уязвимости и много други. Включително и одити. Одитите се провеждат както с вътрешни ресурси, така и с помощта на външни експерти, които могат значително да помогнат за сигурността, тъй като не са потопени в проекта и имат неутрален поглед.

Статията разглежда именно този неутрален поглед на външните експерти, които помогнаха на екипа на Mail.ru Cloud Solutions (MCS) да тестват облачния сервис и какво откриха. За 'външни сили' MCS избраха компанията Digital Security, известна със своята висока експертиза в ИТ сигурността. В тази статия ще разгледаме някои интересни уязвимости, открити по време на външния одит - за да избегнете подобни грешки, когато изграждате своя облачен сервиз.

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

Mail.ru Cloud Solutions (MCS) е платформа за изграждане на виртуална инфраструктура в облака. Тя включва IaaS, PaaS и пазар на готови образи на приложения за разработчици. С оглед на архитектурата на MCS, беше необходимо да се провери сигурността на продукта по следните направления:

защита на инфраструктурата на виртуализацията: хипервизори, маршрутизация, фаерволи;
защита на виртуалната инфраструктура на клиентите: изолация помежду им, включително мрежова, частни мрежи в SDN;
OpenStack и неговите отворени компоненти;
Собствено разработено S3;
IAM: многонационални проекти с ролеви модел;
Vision (машинно зрение): API и уязвимости при работа с изображения;
уеб-интерфейс и класически уеб атаки;
уязвимости на PaaS компонентите;
API на всички компоненти.

Може би значимо за по-нататъшната история - това е всичко.

Какви действия са били предприети и защо са нужни?

Одитът на сигурността е насочен към откриване на уязвимости и конфигурационни грешки, които могат да доведат до изтичане на лични данни, модифициране на чувствителна информация или нарушаване на достъпността на услугите.

В процеса на работа, който обикновено трае 1-2 месеца, одиторите повтарят действията на потенциални злоумышленици и търсят уязвимости в клиентската и сървърната част на избраната услуга. В контекста на одита на облачната платформа MCS бяха поставени следните цели:

Анализ на аутентификацията в услугата. Уязвимостите в този компонент биха могли да позволят незабавно влизане в чужди акаунти.
Изучаване на ролевата модел и разпределението на достъпа между различни акаунти. За злонамереното лице възможността да получи достъп до чужда виртуална машина е желана цел.
Уязвимости на клиентската част. XSS/CSRF/CRLF и др. Може ли да съществува възможност за атака на други потребители чрез злонамерени връзки?
Уязвимости на сървърната част: RCE и всякакви инжекции (SQL/XXE/SSRF и т.н.). Сървърните уязвимости обикновено са по-трудни за намиране, но водят до компрометиране на много потребители наведнъж.
Анализ на изолацията на потребителските сегменти на ниво мрежа. За злонамереното лице отсъствието на изолация значително увеличава повърхността на атака срещу други потребители.
Анализ на бизнес логиката. Може ли да се заблуди бизнесът и да се създават виртуални машини безплатно?

В този проект работата беше проведена по модела "Gray-box": одиторите взаимодействат със сервиза с привилегии на обикновени потребители, но частично разполагат с изходния код на API-то и имат възможност да уточняват детайли с разработчиците. Обикновено това е най-удобният и в същото време реалистичен модел на работа: вътрешната информация все пак може да бъде събрана от злонамерените лица, това е само въпрос на време.

Намерени уязвимости

Преди одиторът да започне да изпраща различни payload’и (полезна натовареност, с която се извършва атаката) на произволни места, е необходимо да се разбере какво как работи, каква функционалност е налична. Може да изглежда, че това е безполезно занимание, тъй като в повечето изучавани места няма да бъдат открити уязвимости. Но само разбирането на структурата на приложението и логиката на неговата работа ще позволи да се открият най-сложните вектори на атака.

Важно е да се намерят места, които изглеждат съмнителни или се отличават силно от другите. И първата опасна уязвимост беше намерена именно по този начин.

IDOR

IDOR уязвимости (Небезопасная прямая ссылка на объект, небезопасни директни референции на обекти) – един от най-честите видове уязвимости в бизнес логиката, който позволява по какъвто и да е начин достъп до обекти, до които всъщност достъп не е разрешен. IDOR уязвимостите създават възможност за получаване на информация за потребители с различна степен на критичност.

Един от вариантите на IDOR е извършването на действия с обекти на системата (потребители, банкови сметки, продукти в кошницата) чрез манипулации с идентификаторите за достъп до тези обекти. Това води до най-недостатъчните последствия. Например, до възможността да се подмени акаунт на изпращача на средства, което може да доведе до кражба на средства от други потребители.

В случая MCS аудитори откриха IDOR уязвимост, свързана с несигурни идентификатори. В личния кабинет на потребителя за достъп до каквито и да е обекти се използваха идентификатори UUID, които изглеждаха, както казват специалистите по сигурността, вдъхновяващо защищени (т.е. защитени от атака чрез подбиране). Но за определени единици беше открито, че за получаване на информация за потребителите на приложението се използват обикновени предсказуеми номера. Мисля, че се досещате, че можеше да се промени ID на потребителя с единица, да се изпрати заявка отново и по този начин да се получи информация в обход на ACL (списък с правила за достъп до данни за процеси и потребители).

Сървърна страна фалшификация на искания (SSRF)

OpenSource продуктите са добри, тъй като по тях има огромно количество форуми с подробни технически описания на възникнали проблеми и, ако имате късмет, с описание на решения. Но от другата страна на медала стои обратната страна: известните уязвимости също са подробно описани. Например, на форума OpenStack има страхотни описания на уязвимостите. [XSS] и [SSRF], които по някаква причина никой не бърза да коригира.

Честата функционалност на приложенията е възможността за потребителя да изпрати на сървъра линк, по който сървърът преминава (например, за да изтегли изображение от указан източник). При недостатъчна филтрация от средствата за сигурност самите линкове или отговорите, връщани от сървъра на потребителите, тази функционалност лесно може да бъде използвана от злонамерени лица.

SSRF уязвимостите могат значително да напреднат атаката. Злоумишленикът може да получи:

ограничен достъп до атакуваната локална мрежа, например само по определени сегменти на мрежата и по определен протокол;
пълен достъп до локалната мрежа, ако е възможно понижение от приложение до транспортно ниво и следователно пълно управление на натоварването на ниво приложения;
достъп до четене на локални файлове на сървъра (ако се поддържа схемата file:///);
и много други.

В OpenStack отдавна е известна SSRF уязвимост, която е с „сляп“ характер: при свързване с сървера не получаваш отговор, но получаваш различни видове грешки/закъснения, в зависимост от резултата на заявката. На базата на това може да се извърши сканиране на портовете на хостовете във вътрешната мрежа, с всички следствия, които не трябва да се подценяват. Например, продуктът може да притежава API за бекофис, достъпен само от корпоративната мрежа. Обладавайки документацията (не забравяме за инсайдерите), злоумишленикът може с помощта на SSRF да се обърне към вътрешните методи. Например, ако е успял по някакъв начин да получи приблизителен списък на полезни URL, с помощта на SSRF може да се премине по тях и да се изпрати заявка – условно казано, да се прехвърлят средства от сметка на сметка или да се променят лимити.

Това не е първият случай на откритие на SSRF уязвимост в OpenStack. В миналото имаше възможност за качване на ISO образи на ВМ чрез директен линк, което също водеше до подобни последствия. В момента тази функция е премахната от OpenStack. Явно, общността е считала, че това е най-простото и надеждно решение на проблема.

А в този в публично достъпен отчет от сървиса HackerOne (h1) експлоатацията вече не е сляпа SSRF с възможност за четене на метаданни на инстанца, което води до получаване на Root достъп до цялата инфраструктура на Shopify.

В MCS на две места с подобна функционалност бяха открити SSRF уязвимости, но почти невъзможно беше да бъдат експлоатирани заради защитни стени и други защити. Така или иначе, екипът на MCS все пак реши проблема, без да чака общността.

XSS вместо зареждане на „шелли“

Въпреки стотиците написани изследвания, година след година XSS (атака междусайтово скриптиране) все още е най- често срещаната веб уязвимост (или атака?).

Зареждане на файлове — любимо място за всеки изследовател на сигурността. Често може да се зареди произволен скрипт (asp/jsp/php) и да се изпълнят команди на ОС, в терминологията на пентестерите — «зареждане на шел» . Но популярността на такива уязвимости работи в двете посоки: за тях се помни и се разработват средства за противодействие, така че напоследък вероятността за «зареждане на шел» стреми към нулата.

На атакуващия екип (в лицето на Digital Security) му провървя. ОК, в MCS на сървърната страна се проверяваше съдържанието на качваните файлове, разрешени бяха само изображения. Но SVG — също е картинка. А какви рискове крият SVG изображенията? Че в тях могат да се вграждат фрагменти от JavaScript!

Оказа се, че качените файлове са достъпни за всички потребители на услугата MCS — значит, може да се атакуват и други потребители на облака, а именно — администраторите.

Пример за внедряване чрез XSS-атака на фишинг форма за вход

Примери за експлоатация на XSS-атаки:

Защо да се опитваш да откраднеш сесия (особено, след като сега навсякъде има HTTP-Only бисквитки, защитени от кражба с помощта на js-скриптове), ако каченият скрипт може да се обърне директно към API на ресурса? В този случай полезният товар може чрез XHR заявки да промени конфигурацията на сървъра, например, да добави отворен SSH ключ на злонамеренец и да получи SSH достъп до сървъра.
Ако CSP политиката (политика за защита на съдържанието) забранява вграждането на JavaScript, злонамеренецът може да се заобиколи без него. На чист HTML да направи фалшива форма за вход на сайта и да открадне паролата на администратора чрез такъв усъвършенстван фишинг: фишинг страницата за потребителя се оказва на същия URL, и е по-трудно да я открият.
Накрая злонамеренецът може да организира клиентски DoS — да зададе Cookies с размер над 4 Кбайта. На потребителя му е достатъчно веднъж да отвори линка — и целият сайт става недостъпен, докато не се досети, че трябва специално да изчисти браузъра: в подавляващото мнозинство от случаите уеб сървърът ще откаже да приема такъв клиент.

Нека да разгледаме пример за още една открита XSS, този път с по-хитра експлоатация. Услугата MCS позволява да се групират настройки на защитната стена. В името на групата беше откритата XSS. Нейната особеност беше, че векторът не сработваше веднага, не при преглед на списъка с правила, а при изтриване на групата:

Тоест, сценарият беше следният: нападателят създава правило на защитната стена с "натоварване" в името, администраторът след известно време го забелязва и инициира процеса на изтриване. И точно тогава злонамереният JS заработва.

На разработчиците на MCS за защита от XSS в качените SVG изображения (ако не могат да бъдат отказани) екипът по цифрова сигурност препоръча:

Да се поставят файловете, качвани от потребителите, на отделен домейн, който няма нищо общо с "бисквитките". Скриптът ще се изпълнява в контекста на друг домейн и няма да представлява заплаха за MCS.
В HTTP отговора на сървъра да се добави заглавие "Content-Disposition: attachment". Така файловете ще се изтеглят от браузъра, а не ще се изпълняват.

Освен това, в момента на разположение на разработчиците са много начини за смекчаване на рисковете от експлоатация на XSS:

чрез флага "HTTP Only" може да се направят сесийните заглавия "Cookies" недостъпни за злонамерен JavaScript;
правилно внедрената CSP политика значително усложнява експлоатацията на XSS за нападателя;
съвременните шаблонизатори, като Angular или React, автоматично почистват потребителските данни преди да бъдат показани в браузъра на потребителя.

Уязвимости на двуфакторната автентикация

За повишаване на сигурността на акаунтите на потребителите винаги се препоръчва да включат 2FA (двуфакторна автентикация). Наистина, това е ефективен начин да се предотврати достъпа на нападателя до услугата, ако данните за вход на потребителя са били компрометирани.

Но винаги ли използването на втория фактор за автентикация гарантира безопасността на акаунта? В изпълнението на 2FA се срещат следните проблеми със сигурността:

Груб брутфорс на OTP кода (еднократни кодове). Въпреки простотата на експлоатацията, такива грешки като липсата на защита от брутфорс на OTP срещат дори големи компании: случаят Slack, случаят Facebook.
Слаб алгоритъм на генериране, например възможността да се предвиди следващият код.
Логически грешки, например възможността да се поиска чужд OTP на собствен телефон, както е е било в Shopify.

В случая MCS 2FA е реализирана на основата на Google Authenticator и Duo. Самият протокол е проверен с времето, а реализацията на проверката на кода от страна на приложението заслужава да бъде проверена.

В MCS 2FA се използва на няколко места:

При удостоверяване на потребителя. Тук има защита срещу подбиране: потребителят има само няколко опита за въвеждане на еднократна парола, след което въвеждането се блокира за известно време. Това блокира възможността за подбиране на OTP чрез опити.
При генериране на офлайн резервни кодове за изпълнение на 2FA, а също така за деактивиране на тази функция. Тук защита срещу подбиране не беше реализирана, което позволяваше, при наличие на парола от акаунта и активна сесия, да се прегенерират резервните кодове или да се деактивира 2FA напълно.

Като се има предвид, че резервните кодове бяха в същия диапазон от стойности, както генерираните от приложението OTP, шансът за подбиране на кода за кратко време беше значително по-висок.

Процесът по подбиране на OTP за деактивиране на 2FA с помощта на инструмента „Burp: Intruder“

Резултат

В общи линии, MCS като продукт се оказа безопасен. През времето на одита екипът по пен тестинг не успя да получи достъп до клиентските виртуални машини и техните данни, а откритите уязвимости бяха бързо отстранени от екипа на MCS.

Но е важно да се отбележи, че безопасността е непрекъсната работа. Услугите не са статични, те постоянно се развиват. Невъзможно е да се разработи продукт без уязвимости. Но е възможно навреме да се откриват и минимализират шансовете за тяхното повтаряне.

В момента всички споменати уязвимости в MCS вече са отстранени. А за да се минимизира бройката на новите и да се съкрати времето на съществуването им, екипът на платформата продължава да прави следното: