by 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/etc. Може, можна атакувати інших користувачів через шкідливі посилання?
- Вразливості серверної частини: RCE та всілякі ін'єкції (SQL/XXE/SSRF тощо). Серверні вразливості, як правило, складніше знайти, але вони призводять до компрометації одразу безлічі користувачів.
- Аналіз ізоляції користувача сегментів на рівні мережі. Для зловмисника відсутність ізоляції значно збільшує поверхню атаки інших користувачів.
- Аналіз бізнес-логіки. Чи можна обдурити бізнес та створювати віртуальні машини безкоштовно?
В даному проекті роботи проводилися за моделлю «Gray-box»: аудитори взаємодіяли з сервісом з привілеями звичайних користувачів, але частково мали вихідні тексти API і мали можливість уточнювати деталі у розробників. Зазвичай це найзручніша і при цьому досить реалістична модель роботи: внутрішня інформація все одно може бути зібрана зловмисником, це лише питання часу.
Знайдені вразливості
Перш ніж аудитор починає відправляти різні payload'и (корисне навантаження, за допомогою якого проводиться атака) у випадкові місця, необхідно розібратися, як працює, який функціонал представлений. Може здатися, що це марна справа, адже в більшості вивчених місць ніяких уразливостей не виявиться. Але тільки розуміння структури застосування та логіки його роботи дасть можливість знайти найскладніші вектори атак.
Важливо знайти місця, які здаються підозрілими або чимось відрізняються від інших. І першу небезпечну вразливість було знайдено саме таким чином.
IDOR
IDOR-уразливості (Insecure Direct Object Reference, небезпечні прямі посилання на об'єкти) — один із найчастіших варіантів уразливостей у бізнес-логіці, який дозволяє тим чи іншим способом отримати доступ до об'єктів, до яких доступ не дозволений. IDOR-уразливості створюють можливість отримання відомостей про користувача різного ступеня критичності.
Один із варіантів IDOR — виконання дій з об'єктами системи (користувачами, банківськими рахунками, товарами у кошику) за рахунок маніпуляцій з ідентифікаторами доступу до цих об'єктів. Це призводить до непередбачуваних наслідків. Наприклад, до можливості заміни облікового запису відправника коштів, за рахунок якої можна красти їх у інших користувачів.
У випадку MCS аудитори виявили IDOR-уразливість, пов'язану з несек'юрними ідентифікаторами. В особистому кабінеті користувача для доступу до будь-яких об'єктів використовувалися ідентифікатори UUID, які здавалися, як кажуть безпечники, небрутабельними (тобто захищеними від атаки перебору). Але для певних сутностей було виявлено, що для отримання інформації про користувачів програми використовуються звичайні передбачувані номери. Думаю, ви здогадуєтеся, що можна було змінити ID користувача на одиницю, надіслати запит заново та отримати таким чином інформацію в обхід ACL (access control list, правила доступу до даних для процесів та користувачів).
Підробка запитів на стороні сервера (SSRF)
OpenSource-продукти хороші тим, що по них є величезна кількість форумів з докладним технічним описом проблем, що виникають і, якщо вам пощастило, з описом рішення. Але ця медаль має зворотний бік: так само докладно розписані й відомі вразливості. Наприклад, на форумі OpenStack є чудові описи вразливостей и , які чомусь ніхто не поспішає виправляти
Часта функціональність програм — можливість для користувача надіслати на сервер посилання, яким сервер переходить (наприклад, щоб завантажити зображення із зазначеного джерела). При недостатній фільтрації засобами безпеки самих посилань або відповідей, що повертаються від сервера користувачам, такий функціонал легко використовують зловмисники.
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 cookie, захищені від крадіжок за допомогою js-скриптів), якщо завантажений скрипт може відразу звертатися до API ресурсу? У цьому випадку корисне навантаження може через XHR-запити змінити конфігурацію сервера, наприклад додати відкритий SSH-ключ зловмисника і отримати SSH-доступ до сервера.
- Якщо CSP-політика (політика захисту контенту) забороняє впроваджувати JavaScript, зловмисник може обійтись без нього. На чистому HTML зверстати фейкову форму входу на сайт і викрасти пароль адміністратора через такий просунутий фішинг: сторінка фішинга для користувача виявляється на тому ж URL, і користувачу її складніше виявити.
- Зрештою зловмисник може влаштувати - виставити Cookies розміром більше 4 Кбайт. Користувачеві достатньо один раз відкрити посилання - і весь сайт стає недоступним, поки не здогадаєшся спеціально почистити браузер: у переважній більшості випадків веб-сервер відмовиться приймати такого клієнта.
Розглянемо приклад ще однієї виявленої XSS, цього разу з хитрішою експлуатацією. Сервіс MCS дозволяє об'єднувати налаштування фаєрволу в групи. В імені групи і була виявлена XSS. Її особливість полягала в тому, що спрацьовував вектор не відразу, не при перегляді списку правил, а при видаленні групи:
Тобто сценарій виходив наступний: зловмисник створює правило фаєрвола з «навантаженням» в імені, адміністратор через деякий час його помічає, ініціює процес видалення. І тут шкідливий JS і відпрацьовує.
Розробникам MCS для захисту від XSS у завантажуваних SVG-зображеннях (якщо від них не можна відмовитися) команда Digital Security рекомендувала:
- Розміщувати файли, що завантажуються користувачами, на окремому домені, який не має нічого спільного з «куковим». Скрипт буде виконуватися в контексті іншого домену і не загрожуватиме MCS.
- У HTTP-відповіді сервера віддавати заголовок "Сontent-disposition: attachment". Тоді файли будуть завантажуватись браузером, а не виконуватися.
Крім того, зараз для розробників є багато способів пом'якшення ризиків експлуатації XSS:
- за допомогою прапора HTTP Only можна зробити сесійні заголовки Cookies недоступними для шкідливого JavaScript;
- значно ускладнить експлуатацію XSS для зловмисника;
- сучасні шаблонізатори, такі як Angular або React, автоматично очищають дані користувача перед виведенням в браузер користувача.
Вразливості двофакторної автентифікації
Для підвищення безпеки облікових записів користувачам завжди рекомендується включити 2FA (двофакторну аутентифікацію). Справді, це ефективний спосіб завадити зловмиснику отримати доступ до сервісу, якщо облікові дані користувача були скомпрометовані.
Але чи завжди використання другого фактора автентифікації дає гарантію збереження облікового запису? У реалізації 2FA бувають такі проблеми безпеки:
- Грубий перебір коду OTP (одноразових кодів). Незважаючи на простоту експлуатації, такі помилки, як відсутність захисту від брутто OTP, зустрічаються і у великих компаній: , .
- Слабкий алгоритм генерації, наприклад, можливість передбачити наступний код.
- Логічні помилки, наприклад, можливість запросити чужий OTP на свій телефон, як це у Shopify.
У випадку MCS 2FA реалізована на основі Google Authenticator та . Сам протокол уже перевірено часом, а ось реалізацію перевірки коду на стороні програми варто перевірити.
MCS 2FA використовується в декількох місцях:
- Під час аутентифікації користувача. Тут захист від перебору є: у користувача всього кілька спроб введення одноразового пароля, потім введення на деякий час блокується. Це блокує можливість провести вибір OTP перебором.
- При генерації офлайнових backup-кодів для виконання 2FA та її відключення. Тут захисту від перебору реалізовано не було, що дозволяло за наявності пароля від облікового запису та сесії, що діє, перегенерувати backup-коди або відключити 2FA зовсім.
Враховуючи, що backup-коди розташовувалися в тому ж діапазоні значень рядків, що і згенеровані додатком OTP, шанс підібрати код за короткий час був вищим.
Процес підбору OTP для відключення 2FA за допомогою інструмента "Burp: Intruder"
Результат
Загалом, MCS як продукт виявився безпечним. За час аудиту команді пентестерів не вдалося отримати доступ до клієнтських ВМ та їх даних, а знайдені вразливості швидко виправлені командою MCS.
Але тут важливо зазначити, що безпека це безперервна робота. Сервіси не статичні, вони постійно розвиваються. А розробити продукт повністю без уразливостей неможливо. Але можна вчасно їх знаходити та мінімізувати шанс їхнього повтору.
Наразі всі згадані вразливості у MCS вже виправлені. А щоб зробити кількість нових мінімальною та скоротити час їх існування, команда платформи продовжує робити це:
- регулярно проводити аудити зовнішніми компаніями;
- підтримувати та розвивати участь;
- займатися безпекою. 🙂
Джерело: habr.com