🥇Одит на сигурността на облачната платформа 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-уязвимости (Insecure Direct Object Reference, небезопасни директни връзки към обекти) са една от най-честите уязвимости в бизнес логиката, които позволяват по един или друг начин достъп до обекти, за които в действителност не е разрешен достъп. IDOR-уязвимостите създават възможност за получаване на информация за потребителя с различна степен на критичност.

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

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

Server Side Request Forgery (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 — да зададе бисквитки с размер над 4 Кбайта. На потребителя му е достатъчно веднъж да отвори линка — и целият сайт става недостъпен, докато не осъзнаеш, че трябва специално да почистиш браузъра: в почти всички случаи уеб сървърът ще откаже да приеме такъв клиент.

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

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

На разработчиците на MCS им беше препоръчано от екипа на Digital Security да следват следните мерки за защита от 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 вече са коригирани. А за да направят броя на новите минимален и да съкратят времето на тяхното съществуване, екипът на платформата продължава да прави следното: