В рубрику "Импортозамещение" | К списку рубрик | К списку авторов | К списку публикаций
Существует ряд способов проверки соответствия приложения заданному белому списку – от проверки пути к исполняемому файлу или его хеша до анализа цифровой подписи и расширения. Средства Application Control чаще всего применяют для дополнительной защиты клиентских компьютеров – запрет на запуск софта не из белого списка – или обеспечения безопасности изолированных систем, не подразумевающих постоянного операторского вмешательства, например банкоматов.
В первом случае нужно защитить пользователя в том числе от фишинговых атак, когда злоумышленник обманом пытается убедить его запустить зловредное приложение, например с помощью письма со специальным вложением. В этом случае система защиты просто запрещает запуск скачанного вложения не на основании поведенческого анализа или сигнатур (которые хакеры все чаще успешно обходят), а просто потому, что такие приложения пользователю запрещено запускать в принципе.
Во втором сценарии подразумевается, что злоумышленник каким-то образом уже проник в систему, т.е. имеет физический или удаленный доступ к системе – к командной консоли cmd.exe или проводнику. Здесь нужно ограничить возможность запуска стороннего софта, который может использоваться для повышения привилегий или выполнения злонамеренных действий (mimikatz, nmap и т.п.).
Поскольку Application Control – молодое направление, почти во всех относящихся к нему инструментах есть те или иные "детские болезни". В итоге такие продукты почти никогда не работают из коробки, их нужно настраивать, тестировать и адаптировать уже по ходу использования. Это объясняется в том числе и сложностями решения самой задачи контроля запускаемых приложений. Перечислим главные.
Если черный список расширений, которые стоит блокировать, более-менее универсальный и его легко сконфигурировать, то белый список того, что разрешено запускать, по умолчанию избыточен: в него зачастую входят все приложения из ОС на момент конфигурации.
А это означает, что выполнить произвольный код в банкомате можно разными способами, не нарушив условия проверок. Например использовав вполне легитимные инструменты, вроде Power Shell (почти всегда банкоматы работают под управлением Windows), а также вызывающих внешний код утилит. За последние несколько лет было описано множество методов обхода Application Control с помощью средств Microsoft Windows (например, rundll32, regsvr32), простая блокировка которых нарушает нормальную работу ОС.
Это означает, что система контроля приложений должна следить не только за фактом запуска этих утилит, но и за целым набором условий: какие процессы используют утилиты (системные или пользовательские), какие права используются, как вызывается нужная библиотека и т.п.
Еще одно направление атаки – интерпретаторы языков программирования (Java, .NET, .PHP). В большинстве случаев условия их запуска на банкомате должны быть максимально детализированы. На деле же это не так, что открывает возможность запуска произвольного кода. Пример возможных последствий – недавно описанная атака на .NET для обхода средств защиты Microsoft Windows Applocker1.
В нашей практике встречались и решения, никак не защищающие от простого обхода контроля расширений с помощью переименования расширения 32-битного файла в произвольное или использования 16-битных приложений, которые никак не проверяются, потому что не содержат PE Header, что обычно является условием проверки файла перед его запуском.
Как видно, существует множество параметров конфигурации, которые необходимо правильно настроить. Имеет также смысл блокировать приложения по заголовкам, а не расширениям, запрещать не только 32-битные, но и 16-битные приложения.
Как и любой другой софт, инструменты защиты могут содержать уязвимости. Ошибки безопасности в антивирусах и межсетевых экранах исследователи находят регулярно – инструменты Application Control стоят в этом же ряду.
В их случае встречаются уязвимости, открывающие возможность проведения сетевых атак, например отключение механизмов защиты простым повторением перехваченной команды или ошибки переполнения буфера. Еще один вид проблем – логические ошибки в работе системы Application Control, их эксплуатация может позволять обходить механизмы защиты2.
Использование инструментов Application Control имеет свою специфику и в зависимости от сферы применения – например, в случае банкоматов важно защититься от атак иного профиля, чем при защите инфраструктуры, скажем, электростанции. В первом случае, чтобы похитить деньги, злоумышленнику не обязательно запускать принесенное с собой вредоносное ПО.
Как показывает наше исследование3, иногда достаточно просто записать или прочитать определенный файл. А для защиты от таких "атак" продукты Application Control не предназначены в принципе, хотя их можно настроить так, чтобы снизить вероятность успеха взломщика. К примеру, при запуске анализа активности, отвечающей за взаимодействие ОС с периферией банкомата библиотеки MSXFS, она может взаимодействовать с тем же Power Shell, а также Regedit и Notepad – блокнота вполне хватит для чтения или записи конфигурационных файлов, так что подобная активность нелегитимных пользователей должна быть запрещена.
Инструменты класса Application Control способны снизить вероятность успешной атаки и усложнить жизнь злоумышленникам, однако по своей сути они не слишком подходят для защиты таких систем, как банкоматы. Существует ряд ограничений, делающих эти инструменты не самым эффективным способом защиты, – от необходимости очень тонкой настройки до вероятности наличия собственных уязвимостей, которые позволяют обойти даже грамотно настроенные правила фильтрации приложений.
Чтобы защитить свою инфраструктуру, банкам следует не просто внедрять инструменты под воздействием текущих трендов, а реализовать комплексную стратегию безопасности – уже в соответствии с ней можно будет осуществить выбор конкретного средства защиты. Какие шаги нужно предпринять для решения этой задачи?
Во-первых, создать модель угроз и модель нарушителя с привлечением независимых экспертов. Во-вторых, разработать политики совместно с аудиторами информационной безопасности и вендором решений Application Control. Придерживаться принципа наименьших привилегий (запрещать все, что явно не должно быть разрешено). И в-третьих – задуматься о внедрении других средств, наличие которых резко сокращает пространство атак для злоумышленника: инструменты контроля подключаемых устройств (Device Control), механизмы защиты от Blackbox-атак с криптографической подписью на стороне процессингового центра.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2017