Pull to refresh

Защита банкоматов: сложности применения продуктов application control

Reading time 5 min
Views 4.4K


Изображение: Pexels

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

Теоретически, инструменты application control можно заменить локальными политиками безопасности ОС, но софт этого класса помогает более гибко управлять политиками черных и белых списков. Сегодня речь пойдет о том, как применять такие средства защиты на реальном примере обеспечения безопасности банкоматов.

Что конкретно делают инструменты application control


Существует ряд способов проверки соответствия приложения заданному «белому» списку — от проверки пути к исполняемому файлу или его хеша, до анализа цифровой подписи и расширения. Средства application control чаще всего применяют для дополнительной защиты клиентских компьютеров — запрет на запуск софта не из белого списка — или обеспечения безопасности изолированных систем, не подразумевающих постоянного операторского вмешательства – например, банкоматов.

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

Во втором сценарии, подразумевается, что злоумышленник каким-то образом уже проник в систему, то есть имеет физический или удаленный доступ к системе — к командной консоли cmd.exe или проводнику. Здесь нужно ограничить возможность запуска стороннего софта, который может использоваться для повышения привилегий, или выполнения злонамеренных действий (mimikatz, nmap и т.п.).

Что здесь может пойти не так: 3 проблемы контроля


Поскольку application control — молодое направление, почти во всех относящихся к нему инструментах есть те или иные «детские болезни». В итоге такие продукты почти никогда не работают из коробки, их нужно настраивать, тестировать и адаптировать уже по ходу использования. Это объясняется в том числе и сложностями решения самой задачи контроля запускаемых приложений — перечислим главные.

Белый список реализовать значительно сложнее


Если «черный список» расширений, которые стоит блокировать более-менее универсальный и его легко сконфигурировать, то «белый список» того, что разрешено запускать, по умолчанию избыточен — в него зачастую входят все приложения из ОС на момент конфигурации.

А это означает, что выполнить произвольный код в банкомате можно разными способами, не нарушив условия проверок. Например, использовав вполне легитимные инструменты, вроде PowerShell (почти всегда банкоматы работают под управлением Windows), а также вызывающих внешний код утилит. За последние несколько лет было описано множество методов обхода application control с помощью средств Microsoft Windows (например, «rundll32», «regsvr32»), простая блокировка которых нарушает нормальную работу ОС.

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

Эксперты Positive Technologies за относительно короткое время смогли расширить список утилит ОС, позволяющих выполнять сторонний код, другими средствами, не упоминавшимися ранее: «debug.exe», “ntsd.exe”, “rasautou.exe” и др.

Еще одно направление атаки — интерпретаторы языков программирования (Java, .NET, PHP). В большинстве случаев условия их запуска на банкомате должны быть максимально детализированы. На деле же это не так, что открывает возможность запуска произвольного кода. Пример возможных последствий — недавно описанная атака на .NET для обхода средств защиты Microsoft Windows Applocker.

В нашей практике встречались и решения, никак не защищающие от простого обхода контроля расширений с помощью переименование расширения 32-битного файла в произвольное или использования 16-битных приложений, которые никак не проверяются, потому что не содержат PE header, что обычно является условием проверки файла перед его запуском.

Как видно, существует очень много параметров конфигурации, которые необходимо правильно настроить. Так же имеет смысл блокировать приложения по заголовкам, а не расширениям, запрещать не только 32-битные, но и 16-битные приложения.

Уязвимости могут быть и в инструментах защиты


Как и любой другой софт, инструменты защиты могут содержать уязвимости. Ошибки безопасности в антивирусах и межсетевых экранах исследователи находят регулярно — инструменты application control стоят в этом же ряду.

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

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


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

Как показывает наше исследование, иногда достаточно просто записать или прочитать определенный файл. А для защиты от таких «атак» продукты application control не предназначены в принципе, хотя их можно настроить так, чтобы снизить вероятность успеха взломщика. К примеру, при запуске анализа активности, отвечающей за взаимодействие ОС с периферией банкомата библиотеки MSXFS, она может взаимодействовать с тем же PowerShell, а также Regedit и Notepad — блокнота вполне хватит для чтения или записи конфигурационных файлов, так что подобная активность нелегитимных пользователей должна быть запрещена.

Заключение: серебряной пули не существует


Инструменты класса Application Control способны снизить вероятность успешной атаки и усложнить жизнь злоумышленникам, однако по своей сути они не слишком подходят для защиты таких систем, как банкоматы. Существует ряд ограничений, делающих эти инструменты не самым эффективным способом защиты — от необходимости очень тонкой настройки до вероятности наличия собственных уязвимостей, которые позволяют обойти даже грамотно настроенные правила фильтрации приложений.

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

  1. Создать модель угроз и модель нарушителя с привлечением независимых экспертов.
  2. Разработать политики совместно с аудиторами информационной безопасности и вендором решений application control. Придерживаться принципа наименьших привилегий (запрещать все, что явно не должно быть разрешено).
  3. Задуматься о внедрении других средств, наличие которых резко сокращает пространство атак для хакера: инструменты контроля подключаемых устройств (device control), механизмы защиты от blackbox-атак с криптографической подписью на стороне процессингового центра.

Автор: Тимур Юнусов, Positive Technologies
Tags:
Hubs:
+4
Comments 1
Comments Comments 1

Articles

Information

Website
www.ptsecurity.com
Registered
Founded
2002
Employees
1,001–5,000 employees
Location
Россия