от SeerLight
Изграждането на всяка услуга задължително включва постоянна работа по сигурността. Сигурността е непрекъснат процес, който включва постоянен анализ и подобряване на сигурността на продукта, следене на новини за уязвимости и много други. Включително одити. Одитите се извършват както от вътрешни, така и от външни експерти, които могат радикално да помогнат със сигурността, защото не са потопени в проекта и имат отворен ум.
Статията е за този най-ясен поглед на външни експерти, които помогнаха на екипа на Mail.ru Cloud Solutions (MCS) да тества облачната услуга, и за това, което откриха. Като „външна сила“ MCS избра компанията Digital Security, известна с високия си опит в кръговете за информационна сигурност. И в тази статия ще анализираме някои интересни уязвимости, открити като част от външен одит - така че да избегнете същия рейк, когато създавате своя собствена облачна услуга.
Описание продукта
е платформа за изграждане на виртуална инфраструктура в облака. Той включва IaaS, PaaS и пазар на готови изображения на приложения за разработчици. Като се има предвид архитектурата на MCS, беше необходимо да се провери безопасността на продукта в следните области:
- защита на инфраструктурата на виртуализационната среда: хипервайзори, маршрутизация, защитни стени;
- защита на виртуалната инфраструктура на клиентите: изолация една от друга, включително мрежа, частни мрежи в SDN;
- OpenStack и неговите отворени компоненти;
- S3 по наш собствен дизайн;
- IAM: проекти с множество наематели с модел за подражание;
- Vision (компютърно зрение): API и уязвимости при работа с изображения;
- уеб интерфейс и класически уеб атаки;
- уязвимости на PaaS компоненти;
- API на всички компоненти.
Може би това е всичко, което е от съществено значение за по-нататъшната история.
Какъв вид работа беше извършена и защо беше необходима?
Одитът на сигурността е насочен към идентифициране на уязвимости и грешки в конфигурацията, които биха могли да доведат до изтичане на лични данни, промяна на чувствителна информация или прекъсване на наличността на услугата.
По време на работата, която продължава средно 1-2 месеца, одиторите повтарят действията на потенциалните нападатели и търсят уязвимости в клиентската и сървърната част на избраната услуга. В контекста на одита на облачната платформа MCS бяха идентифицирани следните цели:
- Анализ на автентификацията в услугата. Уязвимостите в този компонент биха помогнали незабавно да влезете в акаунти на други хора.
- Изучаване на ролевия модел и контрол на достъпа между различни акаунти. За нападателя способността да получи достъп до чужда виртуална машина е желана цел.
- Уязвимости от страна на клиента. XSS/CSRF/CRLF/и др. Възможно ли е да атакувате други потребители чрез злонамерени връзки?
- Уязвимости от страна на сървъра: RCE и всички видове инжекции (SQL/XXE/SSRF и т.н.). Сървърните уязвимости обикновено са по-трудни за намиране, но те водят до компрометиране на много потребители наведнъж.
- Анализ на изолацията на потребителския сегмент на ниво мрежа. За един нападател липсата на изолация значително увеличава повърхността за атака срещу други потребители.
- Анализ на бизнес логиката. Възможно ли е да измамите бизнеса и да създадете виртуални машини безплатно?
В този проект работата беше извършена по модела „Сива кутия“: одиторите взаимодействаха с услугата с привилегиите на обикновените потребители, но частично притежаваха изходния код на API и имаха възможност да изяснят подробности с разработчиците. Обикновено това е най-удобният и в същото време доста реалистичен модел на работа: вътрешната информация все още може да бъде събрана от нападател, това е само въпрос на време.
Открити са уязвимости
Преди одиторът да започне да изпраща различни полезни товари (полезните товари, използвани за извършване на атака) на произволни места, е необходимо да се разбере как работят нещата и каква функционалност се предоставя. Може да изглежда, че това е безполезно упражнение, тъй като в повечето от изследваните места няма да има уязвимости. Но само разбирането на структурата на приложението и логиката на неговата работа ще направи възможно намирането на най-сложните вектори на атака.
Важно е да намерите места, които изглеждат подозрителни или са много различни от другите по някакъв начин. И първата опасна уязвимост беше открита по този начин.
IDOR
IDOR (Insecure Direct Object Reference) уязвимостите са една от най-често срещаните уязвимости в бизнес логиката, която позволява на един или друг да получи достъп до обекти, до които достъпът всъщност не е разрешен. Уязвимостите на IDOR създават възможност за получаване на информация за потребител с различна степен на критичност.
Една от опциите на IDOR е да извършва действия със системни обекти (потребители, банкови сметки, артикули в пазарската количка) чрез манипулиране на идентификаторите за достъп до тези обекти. Това води до най-непредсказуемите последици. Например възможността за замяна на акаунта на подателя на средства, чрез който можете да ги откраднете от други потребители.
В случая с MCS одиторите току-що откриха уязвимост на IDOR, свързана с незащитени идентификатори. В личния акаунт на потребителя UUID идентификаторите бяха използвани за достъп до всякакви обекти, които изглеждаха, както казват експерти по сигурността, впечатляващо несигурни (т.е. защитени от атаки с груба сила). Но за определени обекти беше открито, че редовните предвидими числа се използват за получаване на информация за потребителите на приложението. Мисля, че можете да се досетите, че е възможно да промените потребителския идентификатор с един, да изпратите заявката отново и по този начин да получите информация, заобикаляйки ACL (списък за контрол на достъпа, правила за достъп до данни за процеси и потребители).
Фалшифициране на заявка от страна на сървъра (SSRF)
Хубавото на OpenSource продуктите е, че имат огромен брой форуми с подробни технически описания на възникващите проблеми и, ако имате късмет, описание на решението. Но тази монета има обратна страна: известните уязвимости също са описани подробно. Например във форума на OpenStack има прекрасни описания на уязвимости и , което по някаква причина никой не бърза да поправи.
Обща функционалност на приложенията е възможността потребителят да изпрати връзка до сървъра, върху която сървърът кликне (например, за да изтегли изображение от определен източник). Ако инструментите за сигурност не филтрират самите връзки или отговорите, върнати от сървъра към потребителите, такава функционалност може лесно да бъде използвана от нападателите.
SSRF уязвимостите могат значително да ускорят развитието на атака. Нападателят може да получи:
- ограничен достъп до атакуваната локална мрежа, например само през определени мрежови сегменти и по определен протокол;
- пълен достъп до локалната мрежа, ако е възможно понижаване от ниво на приложение до ниво на транспорт и в резултат на това пълно управление на натоварването на ниво приложение;
- достъп за четене на локални файлове на сървъра (ако се поддържа схемата file:///);
- и много повече.
В OpenStack отдавна е известна SSRF уязвимост, която е „сляпа“ по природа: когато се свържете със сървъра, не получавате отговор от него, но получавате различни видове грешки/закъснения, в зависимост от резултата от заявката . Въз основа на това можете да извършите сканиране на портове на хостове във вътрешната мрежа с всички произтичащи от това последствия, които не бива да се подценяват. Например даден продукт може да има бек-офис API, който е достъпен само от корпоративната мрежа. С документация (не забравяйте за вътрешните лица), атакуващият може да използва SSRF за достъп до вътрешни методи. Например, ако по някакъв начин сте успели да получите приблизителен списък с полезни URL адреси, тогава с помощта на SSRF можете да преминете през тях и да изпълните заявка - относително казано, да прехвърлите пари от сметка в сметка или да промените лимити.
Това не е първият път, когато SSRF уязвимост е открита в OpenStack. В миналото беше възможно да се изтеглят VM ISO изображения от директна връзка, което също доведе до подобни последствия. Тази функция вече е премахната от OpenStack. Очевидно общността смята това за най-простото и надеждно решение на проблема.
И в публично достъпен отчет от услугата HackerOne (h1), използването на вече не сляп SSRF с възможност за четене на метаданни на екземпляр води до Root достъп до цялата инфраструктура на Shopify.
В MCS бяха открити SSRF уязвимости на две места с подобна функционалност, но те бяха почти невъзможни за използване поради защитни стени и други защити. По един или друг начин екипът на MCS отстрани този проблем така или иначе, без да чака общността.
XSS вместо зареждане на обвивки
Въпреки стотиците написани проучвания, година след година атаката XSS (скриптиране между сайтове) все още е най-голямата уеб уязвимост (или ?).
Качването на файлове е любимо място за всеки изследовател на сигурността. Често се оказва, че можете да заредите произволен скрипт (asp/jsp/php) и да изпълнявате команди на OS, в терминологията на pentesters - „зареждане на обвивка“. Но популярността на такива уязвимости работи и в двете посоки: те се запомнят и се разработват средства срещу тях, така че напоследък вероятността за „зареждане на обвивка“ клони към нула.
Атакуващият отбор (представен от Digital Security) имаше късмет. Добре, в MCS от страната на сървъра съдържанието на изтеглените файлове беше проверено, разрешени бяха само изображения. Но SVG също е картина. Как SVG изображенията могат да бъдат опасни? Защото можете да вградите JavaScript фрагменти в тях!
Оказа се, че изтеглените файлове са достъпни за всички потребители на услугата MCS, което означава, че е възможно да се атакуват други облачни потребители, а именно администратори.
Пример за фишинг формуляр за влизане, инжектиран чрез XSS атака
Примери за използване на XSS атака:
- Защо да се опитвате да откраднете сесия (особено след като сега HTTP-Only бисквитките са навсякъде, защитени от кражба с помощта на js скриптове), ако зареденият скрипт може незабавно да получи достъп до API на ресурса? В този случай полезният товар може да използва XHR заявки, за да промени конфигурацията на сървъра, например да добави публичния SSH ключ на атакуващия и да получи SSH достъп до сървъра.
- Ако политиката на CSP (политика за защита на съдържанието) забранява инжектирането на JavaScript, нападателят може да мине и без него. Използвайки чист HTML, създайте фалшив формуляр за влизане в сайта и откраднете паролата на администратора чрез този усъвършенстван фишинг: фишинг страницата за потребителя завършва на същия URL адрес и за потребителя е по-трудно да я открие.
- Най-накрая нападателят може да уреди — задайте бисквитки, по-големи от 4 KB. Потребителят трябва да отвори връзката само веднъж и целият сайт става недостъпен, докато потребителят не реши специално да почисти браузъра: в по-голямата част от случаите уеб сървърът ще откаже да приеме такъв клиент.
Нека да разгледаме пример за друг открит XSS, този път с по-интелигентен експлойт. Услугата MCS ви позволява да комбинирате настройките на защитната стена в групи. Името на групата е мястото, където е открит XSS. Неговата особеност беше, че векторът не се задейства веднага, не при преглед на списъка с правила, а при изтриване на група:
Тоест сценарият се оказа следният: нападателят създава правило на защитната стена с „зареждане“ в името, администраторът го забелязва след известно време и инициира процеса на изтриване. И тук работи злонамереният JS.
За разработчиците на MCS, за защита срещу XSS в изтеглените SVG изображения (ако не могат да бъдат изоставени), екипът за цифрова сигурност препоръчва:
- Поставете файловете, качени от потребителите, в отделен домейн, който няма нищо общо с „бисквитките“. Скриптът ще бъде изпълнен в контекста на различен домейн и няма да представлява заплаха за MCS.
- В HTTP отговора на сървъра изпратете заглавката „Content-disposition: attachment“. Тогава файловете ще бъдат изтеглени от браузъра и няма да бъдат изпълнени.
В допълнение, сега има много начини, достъпни за разработчиците, за смекчаване на рисковете от експлоатация на XSS:
- като използвате флага „Само HTTP“, можете да направите заглавките „Бисквитки“ на сесията недостъпни за злонамерен JavaScript;
- ще направи много по-трудно за нападателя да използва XSS;
- съвременните машини за шаблони като Angular или React автоматично дезинфекцират потребителските данни, преди да ги изведат в браузъра на потребителя.
Уязвимости при двуфакторно удостоверяване
За да се подобри сигурността на акаунта, потребителите винаги се съветват да активират 2FA (двуфакторно удостоверяване). Наистина, това е ефективен начин да се попречи на нападател да получи достъп до услуга, ако идентификационните данни на потребителя са били компрометирани.
Но използването на втори фактор за удостоверяване винаги ли гарантира безопасността на акаунта? Има следните проблеми със сигурността при внедряването на 2FA:
- Грубо търсене на OTP кода (еднократни кодове). Въпреки простотата на работа, грешки като липса на защита срещу OTP brute force също се срещат от големи компании: , .
- Слаб алгоритъм за генериране, например възможността за предвиждане на следващия код.
- Логически грешки, като например възможността да поискате OTP на някой друг на телефона си, като това от Shopify.
В случая на MCS, 2FA е внедрен въз основа на Google Authenticator и . Самият протокол вече е тестван във времето, но прилагането на проверка на кода от страна на приложението си струва да се провери.
MCS 2FA се използва на няколко места:
- При удостоверяване на потребителя. Има защита срещу груба сила: потребителят има само няколко опита да въведе еднократна парола, след което въвеждането се блокира за известно време. Това блокира възможността за избор на OTP чрез груба сила.
- При генериране на офлайн резервни кодове за извършване на 2FA, както и деактивирането му. Тук не беше въведена защита от груба сила, което направи възможно, ако имате парола за акаунта и активна сесия, да генерирате повторно резервни кодове или да деактивирате напълно 2FA.
Като се има предвид, че резервните кодове са разположени в същия диапазон от низови стойности като тези, генерирани от OTP приложението, шансът за намиране на кода за кратко време е много по-голям.
Процесът на избор на OTP за деактивиране на 2FA с помощта на инструмента „Burp: Intruder“.
Резултат
Като цяло MCS изглежда безопасен като продукт. По време на одита екипът за пентестиране не успя да получи достъп до клиентски виртуални машини и техните данни, а откритите уязвимости бяха бързо коригирани от екипа на MCS.
Но тук е важно да се отбележи, че сигурността е непрекъсната работа. Услугите не са статични, те непрекъснато се развиват. И е невъзможно да се разработи продукт напълно без уязвимости. Но вие можете да ги откриете навреме и да сведете до минимум шанса за повторната им поява.
Сега всички споменати уязвимости в MCS вече са коригирани. И за да запази броя на новите до минимум и да намали живота им, екипът на платформата продължава да прави това:
- редовно провеждане на одити от външни компании;
- подкрепа и развитие на участието;
- участват в охраната. 🙂
Източник: www.habr.com