Практика обнаружения атак, использующих легальные инструменты @BIS Summit 2018

Сегодня делал 15-и минутный доклад посвещенный атакам, основанным на штатном функционале легальных инструментов, в секции "Конвергенция последней линии защиты или единственно нужная защита?". Несмотря на то, что тема предвещает сложный контент, презентация была совсем нетехническая, однако, лично у меня все равно сложилось впечатление, что доклад был не формат и следовало бы рассказать про какие-то еще более концептуальные вещи.

Выкладываю презентацию.

Практика обнаружения атак, использующих легальные инструменты from Sergey Soldatov

Времени было 15 минут, а рассказать хотелось о многом, поэтому говорил быстро. Вполне возможно, что что-то не отложилось на слух, поэтому привожу в этом посте кратко драфт скрипта к слайдам.

О чем речь?

В моей презентации я расскажу, что возможность эксплуатации – неизбежное следствие функционала, что уязвимости бизнес-логики существуют на всех уровнях модели OSI. Для обнаружения таких атак требуется экспертиза в бизнес-процессах и такая экспертиза плохо аутсорсится, так как никто не знает наши бизнес-процессы лучше нас самих.

Инфраструктура – первый эшелон

Любое приложение имеет аутентификацию и авторизацию, что является инфраструктурными функциями, а любая атака – это неавторизованный доступ. Поэтому первый эшелон преодоления для атакующего – инфраструктурный.

Анатомия современной таки

Если рассмотреть анатомию современной атаки, то можно сделать следующие выводы.

• Использование специальных инструментов (будем дальше их называть "вредоносное ПО"), если и требуется, то только на этапах компрометации и закрепления. После компрометации и закрепления в сети, как правило, достижение целей выполняется полностью с использованием легальных инструментов: используются учетные записи реальных пользователей, имеющиеся в корпорации системы удаленного доступа и т.п.
• Как мы отметили ранее первый эшелон – инфраструктура, поэтому применение специализированных инструментов для взлома, характерно именно для инфраструктурных компонент системы.
• Поскольку после закрепления атакующий использует легитимные инструменты, вероятность его обнаружения резко снижается со временем. Практика показывает, что чем дольше атака остается незамеченной в системе, тем сложнее от нее потом избавиться\почиститься.

Инфраструктура

Рассмотрим более детально, что творится в инфраструктуре

Мотивация

Как показывает практика, на уровне инфраструктуры тоже можно обойтись без аномалий и вредоносного ПО. На слайде представлена ссылка на выступление от 2013 года, демонстрирующее подход "Living off the land" – выполнение вредоносных действий без использования вредоносного ПО и генерации аномалий. Мотивация понятна: оставаться как можно дольше незамеченным (мы помним, что чем дольше атакующий сидит в инфраструктуре, тем сложнее его оттуда вычистить), во-вторых, не надо тащить с собой инструменты, что само по себе может и не получиться сделать незаметно.

Некоторые примеры нестандартного использования

Здесь, во-первых, на помощь приходят возможности альтернативного использования штатных утилит операционной системы. В целом, такое использование – нестандартно, и это может быть подозрительной аномалией.

Некоторые примеры стандартного использования

Однако, если посмотреть на инструменты, которые можно применять для вредоносных целей, не выходя за рамки их типового использования – их гораздо больше! Если на это использование делать детекты, то ложных срабатываний будет очень и очень много.

За что зацепиться à Детекты/Ханты, Алерты

Чтобы сделать детекты на различные варианты использования легальных утилит в первую очередь нам нужны события сенсоров. Некоторые из них получить несложно, некоторые – требуют ресурсоемкой разработки.

Во-вторых, нужно как-то обеспечивать и контролировать полноту покрытия всех возможных техник нашими детекторами.

В-третьих, нам нужна инфраструктура, способная эффективно обработать собираемые данные. И здесь обязательно встанет вопрос оптимизации.

Ну и, конечно, чтобы понимать какие данные собирать и как их обрабатывать, чтобы обеспечить достойное покрытие, нам нужны исследования. Только исследования, как операционный процесс, позволят обеспечивать стабильно хорошее качество обнаружения.

Конверсия детектов/хантов = NTP/(NTP + NFP)%

Если говорить о поиске и обнаружении атак, основанных на использовании только легальных инструментов, то неизбежен высокий процент ложных срабатываний для детекторов. Для управления ложными срабатываниями хорошей метрикой является конверсия детекта, выраженная в процентах. На основании ее можно определять

• приоритет взятия детектов в работу,
• порядок использования (алерт, который сразу надо расследовать; разметка событий, на которые надо обратить внимание или как обогащение для событий, требующих рассмотрения в совокупности с другими событиями – пример разбивки приведен на слайде)
• ну и, конечно, метрика показывает эффективность детекта – можно сразу определять неэффективные и дорабатывать их.

Приложения и Бизнес-процессы

С инфраструктурой, вкратце, понятно. Перейдем на уровень бизнес-процессов и приложений, их автоматизирующих.

Использование легальных возможностей приложений

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

Лидером, безусловно, является SSO, поскольку благодаря этому чудесному механизму аутентификационные данные (пароли, хеши, билеты Kerberos) хранятся в памяти и их можно оттуда извлекать и в дальнейшем использовать во своему усмотрению.

Следующий пример – субъект, не имеющий сам прав, но имеющий права на назначение прав. Ярким примером здесь является Агент регистрации УЦ (Enrolment agent), который, как правило, не является админом в домене, но может зарегистрировать в УЦ (Enrol) сертификат для учетной записи админа и аутентифицироваться им. Ну и банально, если мы говорим о ERP, например, SAP, то данные, хранящиеся в приложении могут увидеть: админы базиса SAP – если прав нет, могут себе легко дать, админы СУБД – прямо в таблицах базы (в SAP есть функционал шифрования данных в базе, но я не видел, чтобы так кто-то делал), админы ОС, которые могут увидеть данные СУБД.

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

Четвертый пример – про DLP: если я имею доступ к данным, я могу их тиражировать: могу их запомнить, сфотографировать телефоном, переписать ручкой – не важно, я всегда могу унести эти данные с собой.

Последний очевидный пример про накручивание счетчиков. Сайт определяет меня по моей локальной конфигурации, которой я полностью управляю. Здесь проблема в логике и это можно эксплуатировать.

Атаки на бизнес-процессы («лайф-хаки» с оттенками грязи)

Но поднимемся еще выше - на уровень взаимоотношений между людьми, то, что наши приложения автоматизируют. Здесь тоже полно логических ошибок, позволяющих обходить различные ограничения. Я резко отрицательно отношусь к этим «лайф-хаки», порой, попросту мошенничеству. Но, тем не менее, если занимается безопасностью бизнес-процессов, то схемы мошенничества надо очень хорошо знать, чтобы понимать как их можно обнаруживать и предотвращать, отслеживать на уровне каких-либо логов приложений или инфраструктуры.

Итак, есть лоукостеры, которые предлагают весьма выгодные условия перелета, при условии отсутствия багажа. С учетом того, что ручная кладь может достигать 10 кг, а вес чемодана не должен превышать 23 килограмма, получаем, что семья из шести человек в ручной клади может провести багажа на 3 чемодана, что по вещам вполне достаточно на две недели.

Раньше в электричках билеты продавались по тарифным зонам. Например, покупаете билет из пятой зоны до Москвы и обратно. Это позволяло весь день ездить по всем направлениям в пределах пятой зоны, так как не станция, до которой ехать и сколько раз можно проехать нигде не уточнялось.

Что касается схем мошенничества, то их великое множество. На слайде я привел два, скорее, классы, чем конкретные сценарии: карты лояльности и компенсацию расходов по чекам.

Что делать?

Ответ на вопрос что делать очевиден. Понять свои бизнес-процессы – исследовать схемы атак – придумать контроли – построить операционные сервисы управлениям придуманными контролями – анализ метрик этих сервисов позволит совершенствовать весь процесс.

Эпилог 1(2). Безопасность – это компромисс

В завершении, высокоуровнево, хочу отметить, что атаки на бизнес-логику, с использованием штатных возможностей легальных компонентов – следствие широкой функциональности приложений, что, в свою очередь, следствие высоких бизнес-требований. Мы сами постоянно хотим гибкости, широких возможностей, чтобы все можно было конфигурировать – получайте за одно и возможности по эксплуатации.

Эпилог 2(2). Комбинируй эшелоны

Обнаруживать такого рода эксплуатации позволит все тот же эшелонированный подход из контролей на уровне инфраструктуры, приложений, бизнес-процессов и разумная комбинация аутсорсинга и работы внутренних подразделений.

Из зала был один вопрос: "Где в вашем докладе про конвергенцию? Тема нашей секции "Конвергенция последней линии...". Этот же вопрос потом повторился еще к одному докладчику, я решил, что это - критерий неформатности доклада, поскольку остальным спикерам такой вопрос не задавался, полагаю, в их докладах было как раз про конвергенцию. С нетерпением жду записи всех докладов, чтобы повнимательнее ознакомиться с материалом.
Я попытался ответить на этот вопрос, но, по-моему, спрашивающий не был удовлетворен. Что ж, давайте попробуем разобраться здесь, и, если среди читающих мои заметки, есть автор вопроса, надеюсь, мой ответ устроит.
По определению: Конвергенция - это объединение, сближение, схождение. В докладе я рассказывал о том, как на разных уровнях абстракции (инфраструктуре, приложении, бизнес-процессах) мы имеем объекты, объединяющие в себе функционал различного назначения в зависимости от контекста - одна и та же утилита операционной системы, или функция приложения, или свойство бизнес-процесса может нести в себе в одних условиях - желаемое благо (хорошо), а в других - недопустимый ущерб (плохо). Нож - хорошо для нарезки хлеба, но плохо, что им можно убить; вообще, любое оружие - это хорошо для защиты, но плохо, что с его использованием можно совершать преступления. SSO - это хорошо для удобства, но плохо, так как неизбежно приводит к доступности аутентификационных данных из памяти. Программы лояльности - это хорошо, так как это позаоляет привлекать клиентов, но плохо, так как с ними можно придумать много схем мошенничества и, связанные с этим риски, придется как-то адресовать.... В общем, думаю понятно.