23-24 травня пройде чергова конференція Positive Hack Days. Велика частина доповідей (а скільки ще неприйняті заявок ...) присвячена розбору методів атак на веб-додатки і, звичайно, питань захисту. По всьому видно, що тема не тільки не втрачає, а й набирає популярність. Напередодні заходу члени програмного комітету PHDays Андрій Пєтухов і Володимир Дрюков розповідають про свій погляд на безперервну захист веб-додатків.

Погляд з боку дослідників

Спираючись на нашу експертизу в області Application Security, як offensive (аналіз защіщанності, пентести і т.п.), так і defensive (побудова SDLC, розробка SolidWall WAF), вважаємо, що міркування про SOC, безперервному моніторингу та WAF'ах скоро будуть невіддільні від міркувань про безперервну розробці та особливості цього процесу для того чи іншого додатка / сервісу.

• тенденція на зменшення релізний циклу ПО саме як новий тренд відзначалася ще в 2001 році в статті Microsoft Research (візіонер?);
• стаття про Continuous delivery в «Вікіпедії» з'явилася в грудні 2011 року;
• в 2014 році з'явилася Continuous Delivery Conference ;
• в останні 5 років з'являються статті з вивчення спостережуваних феноменів (наприклад, "Continuous Software Engineering and Beyond: Trends and Challenges") з аналізом власного досвіду (наприклад, "Continuous delivery? easy! just change everything (well, maybe it is not that easy )") і т.п.

Короткі релізний цикли переформатують перелік причин і мотивів, які робили за доцільне використання традиційних заходів - залучення зовнішніх консультантів для пошуку недоліків (неважливо, яким способом - «білим» або «чорним» ящиком), ручного тестування власної QA- або security-командою. Дійсно, схема «перевірив код релізу і живи півроку спокійно до наступного» більше не працює. У розробці з короткими релізний циклами перераховані «традиційні» заходи розглядаються вже понад зріло: як джерело зворотного зв'язку на процеси і їх забезпечення всім необхідним - інструментами, людьми, методиками.

Наші консультації з SDLC часто починаються на початковому етапі проекту, коли є тільки ідея. Цільові показники по захищеності розробляється / сервісу ми опрацьовуємо і стверджуємо з замовником на етапі ініціалізації проекту. Залежно від них визначається і затверджується якийсь «паспорт» по досягненню (і контролю) цих показників: набір угод по точкам вбудовування процедур забезпечення захищеності в процес розробки, по застосовуваних інструментів, по зонам відповідальності, за періодичністю (або подій-триггерам) запуску процедур і т.п.

Відзначимо, що безперервність процесів (особливо в частині тестування і розгортання) має на увазі перехід до високого ступеня автоматизації рутинних завдань. Автоматизація відмінно допомагає знизити частоту потрапляння в продукт типових (= зрозумілих) недоліків:

• недоліків, під які написали тести;
• недоліків, під які написали правила для статичного / динамічного аналізатора;
• недоліків, які є наслідком людського фактора (автоматична підготовка оточення; конфігурація і розгортання).

Не такий прямолінійною з ідейної точки зору виявляється тактика боротьби з недоліками інших типів:

• Нетипові недоліки рівня логіки в окремих модулях.
• Недоліки, що з'являються на стику відповідальності різних груп (наприклад, розробників різних сервісів в мікросервісной архітектурі, що виникають під час відсутності явних контрактів, або адміністраторів і devops'ов).
• Недоліки, пов'язані з використанням 3rd-party бібліотек / платформ / фреймворків з опублікованими уразливими. Міркування стосуються в тому числі і бінарних бібліотек, врапперов над якими використовує додаток, і утиліт, які запускаються як окремі процеси (яскравим прикладом будуть уразливості в ImageMagic - CVE-2016-3714, CVE-2016-3715, CVE-2016-3716, CVE -2016-3717, CVE-2016-3718). Важливість своєчасного захисту від атак на недоліки в 3rd-party-компонентах важко переоцінити. У 2017 році практична реалізація масових автоматизованих атак в масштабах всього Інтернету не викликає питань. Прикладами служать недавні набіги на Joomla (наприклад, CVE-2016-8870 + CVE-2016-8869) або Apache Struts (CVE-2017-5638).

Від недоліків перших двох типів можна позбавлятися через whateverbox-аналіз від сторонньої організації, що проводиться з певною періодичністю, або через масове народне безперервне тестування aka Bug Bounty. Недоліки третього типу на етапі складання можна усувати, реалізувавши аналіз зовнішніх залежностей (див. Vulners, WhiteSource, OWASP dependency-check), а на етапі експлуатації - виконанням тих же перевірок тими ж інструментами, але у вигляді окремого завдання і з б про льшей частотою . І нарешті, ще один варіант - захищатися від атак через безперервний моніторинг і реагування.

З точки зору управління процесом розробки, параметри захищеності створюваного ПО / сервісу - звичайні цільові показники, що підлягають плануванню. Тактика досягнення цих показників, по-хорошому, планується на етапі ініціалізації проекту (або на етапі його реформування) і залежить від моделі загроз та оцінки ризиків, обмежень (бюджетних, тимчасових і т.п.), доступних виробничих ресурсів (кваліфікація, методичне забезпечення ) і т.д. Наш досвід показує, що правильно організований моніторинг веб-додатки виконує дві ролі:

• зниження ризиків, пов'язаних з реалізацією загроз через недоліки веб-додатки і його оточення (що очевидно);
• зниження ризиків, пов'язаних з неправильними управлінськими рішеннями, які приймаються в процесі розробки, або з неналежною реалізацією хороших і придатних рішень.

Фактично ми стверджуємо, що наявність правильного моніторингу (наприклад, через сервіс зовнішньої організації) збільшує число ступенів свободи при плануванні тактики досягнення параметрів захищеності створюваного ПО / сервісу на початковому етапі.

Що ж таке правильний моніторинг? Окремо поговоримо спочатку про інструменти, а потім про процеси.

Не секрет, що основним інструментом моніторингу зловмисної активності щодо веб-додатків є кошти класу WAF. Інтернет знає достатня кількість спроб описати, з чого може / повинен складатися хороший WAF. До числа найбільш вдалих можна віднести:

Ми ж пропонуємо свій рейтинг фич, який, за нашим досвідом, вирішує, чи підходить даний інструмент для захисту конкретного додатка. Постановка завдання саме така - порівняти інструменти моніторингу не взагалі, а для конкретного додатка на конкретному стеку технологій.

WAF повинен вміти розуміти прикладної протокол захищається додатки

Тут діє просте правило: якщо WAF не зможе розібрати, яким чином передаються значення параметрів, він не зможе виявити і маніпуляції з цими значеннями (injection / tampering).

Під прикладним протоколом додатки ми розуміємо:

1. Спосіб адресації функцій / ресурсів програми. У найпростіших додатках це частина PATH в URL. Іноді зустрічаються додатки, де URL-шлях завжди однаковий (наприклад, / do), функції адресуються значенням параметра типу "action", а ресурси - параметром типу "page" або "res". У загальному ж випадку функція / ресурс може адресуватися довільним набором атрибутів HTTP-запиту.
2. Спосіб передачі вхідних параметрів, які параметрізуется функції програми. Відзначимо, що специфікація протоколу HTTP ніяк не обмежує фантазію веб-розробників у виборі способу транспорту необхідних даних через структуру HTTP-запиту.

Таким чином, розбір протоколу захищається додатки WAF'ом - це визначення по кожному HTTP-запиту, яка функція програми викликається (який ресурс запитується), з якими параметрами і від чийого імені (якщо мова йде про закритій зоні додатки, доступною після аутентифікації).

Як приклад цікавих протоколів передачі параметрів можна навести такі:

• 3D-Secure. На одному з кроків протоколу інкпасуляція виглядає наступним чином: на сервер приходить POST-запит з типом контенту application / x-www-form-urlencoded, в тілі запиту є параметр PaReq. Параметр PaReq є XML-документом, стисненим за допомогою алгоритму DEFLATE, потім закодованого в Base64 і URL-кодованого. Відповідно, реальні параметри програми передаються в тегах і атрибутах цього XML-документа. Якщо WAF не може розкрити таку «матрьошку» і застосувати політики аналізу до параметрів всередині XML (і / або затверджувати його структуру), значить WAF по суті працює в режимі Fail Open. Інші приклади з цієї ж серії - це численні XML в JSON і навпаки, звичайно, не без допомоги упаковки в BASE64.
• Google Web Toolkit та інші протоколи, які використовують власний сериализацию (НЕ JSON / XML / YAML / ...). Замість тисячі слів - один приклад запиту:


Відповідно, якщо WAF не може отримати з запиту кінцеві значення параметрів, з якими оперує захищається додаток, то WAF не працює. Відзначимо, що існує пристойна кількість способів сериализации бінарних об'єктів (а ще можна запив свій власний!).
• Oracle Application Express (APEX). URL додатка в APEX виглядають приблизно так: http://apex.app:8090/apex/f?p=30:180:3426793174520701::::P180_ARTICLE_ID:5024 . POST-запити в URL-частини - аналогічно, а параметри передаються в тілі (x-www-urlencoded), але назви незалежно від спричиненої операції - однакові: x01 = val1 & x02 = val2 ... і т.п. Ось приклад запиту:
• 

Якщо в перших двох прикладах розбір протоколу був потрібний для визначення значень вхідних параметрів, то в додатках такого типу WAF додатково повинен зрозуміти, яка запитується операція або ресурс. Зауважимо, що ніхто не заважає розробникам додатків на APEX в параметрах x01, x02 і т.д. передавати, наприклад, XML / JSON, закодований в base64, або, як на останньому знімку, серіалізовані X-WWW-URLENCODED параметри.

WAF повинен мати гранулярность рівня операцій захищається додатки

Додатки на APEX відмінно ілюструють наступну тезу: WAF повинен застосовувати свої механізми / політики / правила не з гранулярністю сутностей HTTP-протоколу (секції URL, заголовки і їх значення, імена параметрів і їх значення), а з гранулярністю функцій програми і їх вхідних параметрів.

Дійсно, для додатка на APEX параметри x01, x02 і т.п. будуть транспортом значень для всіх його функцій, але:

• інкапсуляція значень цих параметрів може бути різною (див. значення x01 на знімках екрану вище);
• як наслідок, типи, області значень і семантика цих параметрів будуть відрізнятися!

Виходить, що від механізмів WAF ми хочемо наступного:

• Підсистема побудови і застосування позитивних моделей повинна будувати не одну загальну позитивну модель на основі всіх спостережуваних значень параметра x01, а N моделей за кількістю функцій програми, які приймають цей параметр.
• Підсистема сигнатурного аналізу повинна застосовувати до параметру x01 не один і той же набір сигнатур, а K наборів (К £ N) в залежності від побажань оператора по покриттю сигнатурами значень x01 для дій або їх груп.
• Якщо ж оператор захоче налаштувати для параметра x01 якесь додаткове правило (наприклад, придушення помилкового спрацьовування), то він повинен мати можливість вибирати scope роботи цього правила не в термінах протоколу HTTP (регулярний вираз над URL, наприклад), а знову ж таки в термінах функцій програми, які приймають x01.

Автори даної статті зустрічалися з ситуацією, коли на WAF одного великого вендора не працював User Tracking (Механізм User Tracking дозволяє зв'язати запити, надіслані користувачами програми після аутентифікації, з їх логінами. Для конфігурації цього механізму інструменти зазвичай вимагають ввести критерії успішного логіна, неуспішного логіна і критерії інвалідаціі сесії (тайм-аут по бездіяльності при наявності, новий вхід під тим же користувачем, відправка logout запиту по заданому URL і т.п.)) на APEX-додатку якраз через те, що правила для розділі ня успішного login-дії, неуспішного login-дії, logout-дії та інших дій неможливо було задати наданими виразними засобами, це були регулярні вирази над полями HTTP-запиту.

Наведені міркування справедливі, звичайно, не тільки для APEX-додатків, але і для різних додатків зі складною маршрутизацією не на основі URL: XML-RPC, JSON-RPC, SOAP і т.п.

Погляд з боку SOC

Але чи є установка WAF панацеєю і справжньою «срібною кулею»? І що робити безпечники, який зіткнувся з цим рішенням, як вичавити з технології все соки і максимум можливостей: забезпечити не тільки адміністрування, а й ефективне виявлення та реагування на атаки?

Світ enterprise-клієнтів, особливо інтернет-компаній, впевнено прагне від циклу швидких релізів (раз на місяць / два) до динаміки практично безперервної розробки (3-4 релізу в тиждень). У цьому випадку навіть можливості по автоматизованої захисту і навчання додатків, що надаються поточними вендорами WAF, стикаються з труднощами. Ми б хотіли розповісти про це, спираючись на досвід діяльності комерційного центру моніторингу і реагування на кібератаки Solar JSOC

Одним з найбільш важливих аспектів, пов'язаних з WAF, крім вибору вендора і впровадження продукту, є подальша експлуатація рішення. При цьому класичний підхід до експлуатації Web Application Firewall підходить дуже умовно і має ряд важливих особливостей:

1. З огляду на розташування WAF і природи захищаються їм ресурсів однієї з найважливіших завдань є відновлення сигнатур і оперативне встановлення патчів, в тому числі закривають помилки. Зволікання на кілька днів може загрожувати серйозними втратами і зломом захищається ресурсу.
2. На передній план виходять проактивний експлуатація, що передбачає реагування на інциденти в режимі, близькому до онлайн, аналіз і оперативний тюнінг політик і профілів WAF.
3. В силу скорочення релізний циклу проблема динамічного контенту і профілювання вимагає наявності фахівців з експлуатації в режимі full-time.

Ці особливості одночасно є основними причинами для передачі експлуатації даного рішення на аутсорсинг. Нижче хотілося б розглянути особливості, пов'язані з проактивним експлуатацією Web Application Firewall в сучасних реаліях.

експлуатація WAF

1. Оновлення - відстеження патчів, в тому числі закривають помилки.
2. Написання приватних сигнатур:

• відстеження нових критичних сигнатур, спільні з замовником тестування і підготовка контрзаходів на період, поки не випущені офіційні оновлення.
• написання сигнатур в якості компенсаційних заходів щодо закриття вразливостей вихідного коду додатків:
• уразливості відомі розробникам, закриття яких вимагає масштабних доробок вихідного коду;
• уразливості, виявлені в результаті аналізу вихідного коду додатків, наприклад, за допомогою сканера Solar InCode.

3. Профілювання запитів, звернень до URL.
4. Validation - перевірка і аналіз параметрів запитів, відповідей на захищається ресурс, додаток.

При цьому лише перший з перерахованих вище пунктів можна виконувати автономно від відділу розробки. Всі інші функції експлуатації нерозривно пов'язані з розробниками захищається веб-сайту або програми. Не менш важливу роль відіграє тестування зібраних профілів, в тому числі в режимі блокування запитів.

Думаю, не викликає сумнівів те, що варіант «прийшов-настроїв-включив-працює» в 99% випадків не життєздатний.

Режим роботи WAF

Перший варіант: тільки блокування - по сигнатурам і профілем. Тут треба враховувати два моменти: 1) є ризик заблокувати легітимні запити; 2) необхідно аналізувати атаки. Іноді трапляється, що 99% запитів заблоковано, а 1% пройшов. За фактом аналізу цього 1% пишуться і додаються до блоку нові кастомниє сигнатури.

Другий варіант: тільки повідомлення. У цьому випадку за фактом спрацювання сигнатур необхідно проводити комплексне розслідування і корелювати дані з іншими джерелами, наприклад, з базами даних в разі використання SQL-ін'єкцій.

Однак найчастіше використовується третій варіант - гібридний.

Який би варіант ви не вибрали, важливо пам'ятати про необхідність аналізувати як запити, що викликали спрацьовування, так і пропущені запити до додатка.

кастомниє сигнатури

Одним з важливих моментів в експлуатації Web Application Firewall є написання кастомних сигнатур. Потрібно це в декількох випадках: поява нової уразливості, реєстрація аномалій, які потребують додаткового аналізу, і збір довготривалої статистики аутентифікації в додатку.

У разі з'явиться серйозної уразлівості, Який, например, булу shellshock, потрібна оперативна доопрацювання політики. Служба ЕКСПЛУАТАЦІЇ WAF может реалізуваті ее в течение 1-2 годин, в тій годину як вендору может знадобітіся до декількох діб. Зволікання в таких ситуаціях загрожує успішної експлуатацією уразливості, так як зловмисники працюють практично миттєво, запускаючи сканування всіх білих адрес в інтернеті на схильність уразливості.

Прикладом виявлення аномалій за допомогою ручного аналізу служить збір статистики по великому обсягу віддається і одержуваного трафіку. У загальному випадку великий обсяг сесії не говорить про інцидент, але при перегляді загальної статистики можна знайти дійсно важливі спрацьовування. Аналогічний кейс пов'язаний з моніторингом завантажених файлів з нестандартними розширеннями. У загальному випадку блокування таких вкладень недоцільна, але їх аналіз, в тому числі з використанням пісочниці, є рекомендованим.

Робота з динамічний контентом

Правильний цикл роботи з постійно змінюються контентом, з нашої точки зору, повинен виглядати наступним чином:

1. Сформована політика вивантажується з бойового сервера в тестову середу.
2. В процесі тестування оновленого контенту одночасно тестується сумісність з поточною політикою WAF, в разі необхідності проводиться її коригування.
3. В ідеальній схемі оновлення додатка або сервісу тестується на пілотній групі (регіоні). На цьому етапі політика WAF перекладається в блокуючий режим і тестується в бойових умовах. Так само здійснюється тюнінг і тонка настройка конфігурації політики.
4. Далі оновлення і політика застосовується глобально до всіх клієнтів замовника і стає еталонною до наступного оновлення.

В ідеальному світі є тестова среда, функціональні і навантажувальні тести тривалістю приблизно в 2 тижні. Але життя іноді розставляє все по-іншому. Приблизно в 30% випадків нам доводиться працювати зі скороченим режимом розробки додатків і веб-сайтів у замовників, коли оновлення відразу «накочується» на продуктивні сервери. В цьому випадку необхідно оперативно підлаштувати політику WAF під нові умови роботи. Для цього профілювання запускається на короткий проміжок часу - півдня-день. Через великий обсяг трафіку цього часто досить для навчання. Через зазначений час «допрофілірованная» оновлена ​​політика переводиться в блокуючий режим.

Обидва методи вимагають додаткової уваги з боку служби експлуатації в період переведення в блокуючий режим. Це робиться для ручного аналізу заблокованих запитів, так як ніяка інтелектуальна система навчання і профілювання не може працювати ідеально без хибнопозитивних спрацьовувань.

Ось два яскраві приклади циклу розробки у наших клієнтів:

Перший випадок - замовник випускає один реліз на тиждень. При цьому взаємодія між замовником і підрядником не передбачає детального release notes, за яким можна зрозуміти, чи потрібна коригування політики. Єдиний варіант - робота «на гарячу» з коротким і оперативним циклом тюнінгу політики WAF:

В іншому нашого клієнта частина сайту змінюється кілька разів на день в рамках розміщення нових продуктів, акцій і т.д. Включати на цю частину контенту сайту якесь профілювання і блокування по зібраному профілем неможливо. Тому ми працюємо по цій частині в режимі моніторингу аномалій і створення кастомних сигнатур.

Додаткова кореляція для аналізу інцидентів

Якщо компанія використовує власний або аутсорсинговий Security Operations Center, підключення WAF до SIEM-системі дозволить налагодити оперативне повідомлення і розбір за всіма типами інцидентів, в тому числі і веб-атакам, з однієї точки - SIEM-системи. Фахівці першої лінії моніторингу можуть фіксувати кореляційні спрацьовування, налаштовані за різними сценаріями:

1. Аномальне кількість різних сработавщіх на WAF сигнатур з зовнішнього хоста - потенційне сканування на уразливості.
2. Спрацювання сигнатур протягом декількох днів поспіль з одного зовнішнього хоста - повільне сканування.
3. Спрацювання порогового значення сигнатур за короткий проміжок часу з різних хостів - розподілене сканування / DDoS рівня додатки.

Після того як фахівці першої лінії сповістять службу експлуатації WAF, останні мають можливість підключитися вже до інтерфейсу СЗІ і в режимі реального часу «тюнить» політики для протидії атаці.

ідключення до SIEM-системі дозволяє не тільки налагодити оперативне оповіщення про спрацювання WAF, а й збагачувати інформацію про атаки відомостями з інших систем, а також виробляти складну кореляцію по ланцюжках подій. Наприклад, для розуміння успішності атаки інформацію з Web Application Firewall можна корелювати з успішними запитами в SQL-базах даних або локальними балками веб-сервера.

Наш підхід до обробки інцидентів:

Але і це далеко не всі підводні камені. Найскладнішими в детектировании є атаки на логіку програми (хоча їх відображення, можливо, не є завданням WAF).

Наприклад, в одному з наших замовників ключовим бізнес-компонентом є інтернет-магазин. Всі існуючі бізнес-процеси «зав'язані» на логіку роботи з клієнтами і обробку замовлень. Як програма лояльності компанія використовує віртуальні бали, які можуть застосовуватися для розрахунку з магазином, в тому числі часткового. Клієнт при оформленні покупки на етапі вибору способу оплати має можливість ввести в поле число балів, яке буде використано замість реальних грошей.

Замовнику необхідно контролювати підозрілі операції - занадто велика кількість списаних бонусів або транзакцій з бонусами за певний час. Як інструмент для збору зведеної статистики використовується окрема таблиця (Active List в ArcSight). Щоденна вивантаження з цього листа відправляється аналітику для вивчення аномалій, що не потрапляють в поточні кореляційні спрацьовування.

В одній з таких вивантажень була виявлена ​​запис:
«Modify_order_bonus": "{\" bonusAvailable \ ": 18.0, \" bonus \ ": - 20000}" reason: success »

При розборі цієї аномалії з'ясувалося, що один з клієнтів намагався POST-запитів, що містять різні варіації необхідних до списання бонусів, обдурити логіку веб-сайту. І домігся свого! При відправці від'ємного значення система порівнювала кількість наявних бонусів з числом бонусів до списання і при виконанні математичного нерівності схвалювала процес.

Але і це ще не все: при подальшій обробці замовлення в спеціалізованих системах, куди передавалася інформація з веб-сайту, значення необхідних до списання бонусів бралося по модулю! Так клієнт успішно отримав знижку в 20 тисяч рублів при наявності на рахунку 18 балів.

Web Application Firewall не побачив нічого аномального, так як структура запиту була правильною, і кількість запитів не було підозрілим. Лише наступний збір статистики і перегляд подій очима живого аналітика дозволив виявити успішну спробу шахрайства в ключовому бізнес-додатку клієнта.

Звідси висновок: будь-які важливі запити до ключового додатком, такі як списання балів, грошових коштів та ін., Необхідно Залогуватися за допомогою налаштувань кастомних політик на WAF або за допомогою підключення логів програми та подальшого аналізу в SIEM-системі.

Захист оточення додатків

Далеко не всі хакери атакують додаток «в лоб». У частині випадків значно простіше проникнути в інфраструктуру компанії і атакувати додаток або його базу зсередини, щоб вносити зміни безпосередньо. Крім цього, існують внутрішні зловмисники, в тому числі мають доступ до додатка, і за ними необхідний не менший контроль.

Вирішити це завдання силами WAF неможливо, це робота для SIEM-системи. Підключення логів операційних систем серверів додатків, баз даних, допоміжних систем, термінальних серверів, а також безпосередньо самої бази даних і додатки, хоча б на рівні аутентифікації (а краще безпосередніх запитів), дозволяє контролювати всі дії в бізнес-системі клієнта і, укупі з WAF, протидіяти майже всім доступним для огляду векторах загроз.