Защита от угроз атак на уязвимости приложений, исполняемых непривилегированными учетными записями
Проведенный общий анализ архитектуры КСЗИ «Панцирь+» (что было проиллюстрировано ранее) показал, что она построена как эшелонированная (уровневая) система защиты, где реализация каждого последующего уровня защиты предполагает преодоление злоумышленником защиты предыдущего уровня. В данном случае предполагаем, что в системе запущена вредоносная программа с правами пользователя.
Основу реализации изолированной обработки данных пользователями в КСЗИ «Панцирь+» составляет использование метода контроля доступа к создаваемым файлам.
Проведенный анализ способов защиты КСЗИ «Панцирь+» и их применения.
С этой целью создадим двух субъектов доступа, см. рис.34, и зададим для них соответствующую разграничительную (в данном случае, разделительную) политику доступа, см. рис.35. При этом субъект доступа в разграничительной политике идентифицируется именем, присвоенным ему при создании.
Рис. 34. Созданные субъекты доступа
Рис. 35. Созданные правила доступа
Все создаваемые обоими пользователями, поскольку они отнесены к субъектам - создателям контролируемых файлов, см. рис.35, файлы будут автоматически размечаться при создании, доступ же к ним при этом будет возможен только в рамках заданных правил.
Как видим, заданными правилами (всего двумя) обработка данных между двумя пользователями в системе становится полностью изолированной (еще требуется изолировать между ними буфер обмена, о том, как это делается, далее).
Проверка корректности разметки создаваемых файлов.
Проверка требуется ввиду того, что многими приложениями создаются временные файлы, доступ к которым также необходимо разграничивать.
В рамках проведения соответствующей проверки проведено испытание, для чего было создано правило, при котором контролируется доступ ко всем файлам, создаваемым в системе пользователем «Татьяна» Все создаваемые под этой учетной записью файлы автоматически размечаются). Под этой учетной записью был создан в текстовом редакторе файл, и используя соответствующую утилиту из состава КСЗИ «Панцирь+» определена его разметка в файловой системе, проиллюстрированная на рис.36.
Рис. 36. Разметка созданного файла
Проведенное испытание показало, что автоматически был размечен и собственно созданный файл и соответствующий ему временный файл, что позволяет сделать вывод о корректности разметки файлов.
Вывод. Контроль доступа к создаваемым файлам в в КСЗИ «Панцирь+» реализован корректно, т.к. любой создаваемый файл (любого типа) при создании будет КСЗИ «Панцирь+» автоматически размечаться.
Замечание. Проведенный анализ позволяет сделать и следующий вывод.
Вывод. В случае использования данного механизма защиты для разграничения прав доступа к файлам, создаваемым различными пользователями, не требуется дополнительного разделения между ними неразделяемых папок (папок коллективного использования), в частности каталогов, используемых приложениями для временного хранения файлов.
Аналогичным образом можно реализовать и защиту обрабатываемых в информационной системе данных от внедренной с правами пользователя вредоносной программы, но здесь уже понадобится задание субъекта доступа процесс.
Идея защиты, опять же реализуемой в общем виде, состоит в предоставлении возможности пользователям обрабатывать данные только легальными (легально установленными в системе) приложениями. Эта задача решается следующим образом.
Пусть вся обработка данных осуществляется пользователем исключительно программами из офисного пакета. Для реализации разграничительной политики доступа требуется создание двух субъектов доступа, см. рис.36, и создания для них соответствующих правил доступа, см. рис.37.
Рис. 36. Созданные субъекты доступа
Рис. 37. Созданные правила доступа
Как видим из представленных настроек, любой создаваемый программой из офисного пакета файл будет автоматически размечаться, последующий же доступ к такому файлу будет возможен исключительно программе из офисного пакета.
Проверка корректности обработки запросов доступа для субъекта доступа пользователь, процесс.
Необходимость проведения данной проверки обусловливается тем, что в основу защиты от угроз атак на уязвимости приложений, исполняемых непривилегированными учетными записями, положена реализуемая КСЗИ «Панцирь+» возможность разграничивать права доступа для процессов, исполняемых под одной и той же учетной записью.
В рамках проведения соответствующей проверки проведено испытание, для чего было создано для одной учетной записи «Татьяна» два субъекта доступа, предполагающих обработку данных различными редакторами, см. рис.38, и соответствующие два правила, запрещающие доступ различных субъектов к различным файлам, см. рис.39.
Рис.38. Созданные субъекты доступа
Рис.39. Созданные тестовые правила доступа
Испытание состояло в запросе доступа различных субъектов под одной учетной записью к разрешенному и запрещенному файлам, результаты аудита доступа, из которых следует вывод о корректности обработки запросов доступа субъектом пользователь, процесс, представлены на рис.40.
Рис.40. Регистрация запросов доступа
Вывод. КСЗИ «Панцирь+» обеспечивает разграничение прав доступа под одной учетной записью для различных приложений.
Вывод. В КСЗИ «Панцирь+» реализация разграничительной политики доступа для субъекта пользователь, процесс корректна.
Замечание. Проверка проведена на механизме контроля доступа к статичным объектам.
В общем случае угроза атаки на рассматриваемом пользовательском уровне может создаваться соответствующими возникающими уязвимостями приложений, эксплуатация которых не требует использования вредоносного исполнимого или командного файла. При этом вероятность наделения различных приложений вредоносными свойствами может сильно различаться. Основу подобных атак составляет использование злоумышленниками методов социальной инженерии, направленных на то, чтобы убедить пользователя открыть зараженный файл, присылаемый по электронной почте или иным способом по сети, либо перейти по предоставляемой ссылке на зараженный сайт.
Пример. В апреле 2017 года разработчики Microsoft представили исправление для уязвимости CVE-2017-0199, которая затрагивала Microsoft Office. Ошибка связана с некорректной обработкой ответов от сервера в функции Microsoft OLE (Object Linking and Embedding), которая дает возможность встраивать одни документы внутрь других. После открытия зараженного документа приложение делает запрос на удаленный сервер, чтобы получить встроенный в этот документ файл. Сервер возвращает специально сформированный ответ. В нем содержится вpедоносный файл HTA, код из которого после загрузки выполняется на целевой системе. При этом, если сначала для атак использовались документы Rich Text File (RTF), то сейчас злоумышленники переключились на PowerPoint Show (файлы PPSX), которые распространяются вместе со спамерскими письмами, в виде вложений.
Особую опасность несут в себе браузеры, которые могут скачать с вредоносного сайта страницу с активным содержимым (скриптом), при этом оно будет выполнено без сохранения в файл.
Защита от угроз атак на уязвимости приложений в КСЗИ «Панцирь+» основана на реализации процессной модели контроля доступа (разграничение между процессами) к создаваемым файлам.
Сначала рассмотрим реализацию защиты от атак на браузеры. Для этого требуется создать соответствующий субъект доступа «Браузер», исходя из того, что в системе используется IE, см. рис.41, и создать для него соответствующую разграничительную политику доступа к создаваемым файлам, см. рис.42.
Рис.41. Созданный субъект доступа «Браузер»
Рис.42. Пример разграничительной политики доступа к создаваемым файлам
При такой разграничительной политике доступа каждый создаваемый файл будет в системе автоматически размечаться – наследовать учетные данные создавшего его субъекта доступа. Ознакомиться с автоматически созданной разметкой файлов (при необходимости ее удалить или изменить, а также создать вручную) можно с использованием соответствующей утилиты, входящей в состав КСЗИ «Панцирь+», что было проиллюстрировано ранее.
Правилами, приведенными на рис.42, браузеру разрешается доступ (за исключением исполнения) только к созданным им же файлам, остальным субъектам доступа запрещается исполнение файлов, созданных браузером. Поскольку через браузер можно скачать зараженный документ, то в общем случае работу браузера целесообразно в системе полностью изолировать, запретив всем субъектам любой доступ к файлам, созданным браузером.
Полнота решения задачи обработки данных в информационной системе обеспечивается реализацией в КСЗИ «Панцирь+» соответствующих дополнительных механизмов защиты обрабатываемых данных - механизма контроля и разграничения прав доступа к буферу обмена, и очистки остаточной информации в оперативной памяти, интерфейсы которых приведены на. рис.43.
а. Меню задания правил доступа к данным, помещаемым в буфер обмена, и созданные правила доступа для браузера
б. Меню задания правил очистки остаточной информации в оперативной памяти
Рис.43. Интерфейсы дополнительных механизмов защиты обрабатываемых данных
Механизмом контроля доступ к буферу обмена разграничивается доступ не собственно к буферу обмена, а к данным, помещаемым в него приложениям для временного хранения, т.е. к создаваемым в буфере обмена данным.
При этом механизмом защиты запоминается то, каким субъектом помещены данные в буфер обмена, при обращении же к буферу обмена анализируется корректность запроса доступа – его непротиворечивость заданным правилам. Правилами, проиллюстрированными на рис.43.а, браузеру запрещается доступ к данным, помещенным в буфер обмена иными субъектами.
В общем случае буфер обмена может использоваться злоумышленниками не только для воздействия на обрабатываемые данные, но и для осуществления атаки, т.е. данный ресурс также несет в себе угрозу атаки.
Проведенный анализ угрозы атаки.
В качестве примера использования буфера обмена для осуществления целевых атак может быть приведена известная угроза атаки воровства денег в системе WebMoney. Данная атака основана на внедрении на компьютер пользователя небольшой троянской программы, которая отслеживает, открыто ли окно программы WebMoney. В случае если оно открыто, осуществляется мониторинг буфера обмена. При обнаружении в буфере текста, начинающегося с «Z», «R» или «E», троянская программа считает, что это номер кошелька получателя, который пользователь скопировал в буфер обмена для ввода в окне WebMoney. Этот номер удаляется из буфера и заменяется на номер «Z», «R» или «E» кошелька злоумышленника. Метод крайне прост в реализации и может быть достаточно эффективным, поскольку номера кошельков действительно чаще всего не вводятся, а копируются через буфер и далеко не все пользователи тщательно проверяют, тот ли номер кошелька вставился из буфера обмена.
Механизм очистки остаточной информации в оперативной памяти, настройка которого проиллюстрирована на рис.43.б, позволяет зачищать всю информацию в областях оперативной памяти, не занятых соответствующими процессами, причем, как при запуске какого-либо приложения, в первую очередь, критичного к заражению, так при завершении какого-либо приложения, например, используемого для обработки конфиденциальной информации. На рис.43.б приведен пример настройки, при которой и при запуске и при завершении процесса браузер, будет автоматически удалять остаточная информация в свободной области оперативной памяти.
Как отмечали ранее, различные приложения характеризуется различным уровнем угрозы – вероятностью наделения их вредоносными функциями.
Проведенный анализ статистики выявленных уязвимостей.
На рис.44 представлена сводная таблица от CVE числа выявленных уязвимостей в различных программных средствах за 2016 год.
Рис.44. Статистика CVE уязвимостей за 2016 год
Как видим (кроме устрашающего числа обнаруженных за год уязвимостей для различных программных средств), к наиболее уязвимым приложениям, кроме браузеров, можно отнести Flash Player и Acrobat Reader, работу которых, по полной аналогии с тем, как это было сделано выше для браузера, следует изолировать от работы иных приложений – запретить им доступ к создаваемым иными приложениями файлам.
В том числе, для этих приложений целесообразно предотвратить (если это возможно) обработку соответствующих файлов, загружаемых из сети. С этой целью следует запретить им доступ к файлам, создаваемым, например, почтовым клиентом (к сохраняемым файлам, содержащим собственно письмо и соответствующее вложение).
Вывод. Разграничительная политика доступа для субъекта процесс должна создаваться в КСЗИ «Панцирь+», исходя из вероятности наделения различных процессов вредоносными свойствами, за счет эксплуатации выявляемых в приложениях уязвимостей, и способов наделения приложений вредоносными свойствами.
Теперь, что касается вредоносных командных файлов (скриптов). Опять же задача защиты решается в предположении о том, что командный файл может быть внедрен на защищаемый компьютер (реализуется эшелонированная защита).
Подход к защите КСЗИ «Панцирь+» в данном случае остается прежним.
Проиллюстрируем, как нейтрализовать угрозу атаки на уязвимости java-машины, в предположении о том, что java-машина должна использоваться для работы только с локальными приложениями. В этом случае может быть сформулирована и решена реализацией контроля доступа к создаваемым файлам задача защиты, состоящая в следующем - предотвратить возможность доступа java-машине к коду, внедренному из внешней сети.
Предположим, что в качестве сетевого приложения используется браузер IE, которым потенциально может быть внедрен вредоносный код из внешней сети, а в качестве java-машины - java.exe JVM от Oracle (процесс java.exe). Соотвественно, это те субъекты доступа, для которых необходимо реализовать разграничительную политику доступа, см. рис.45.
Рис.45. Созданные субъекты доступа
Рассматриваемая задача защиты решается заданием в разграничительной политике доступа всего одного правила, см. рис.46.
Рис.46. Созданное правило контроля доступа к создаваемым файлам
При реализации правила доступа, приведенного на рис.46, браузер не сможет получить доступ к загружаемым из сети командным файлам (скриптам).
Вывод. Задача защиты от угроз атак на уязвимости приложений решается КСЗИ «Панцирь+» в общем виде, в том смысле, что ее решение не требует детектирования с использованием сигнатурного анализа зараженных документов, при этом минимизируется возможный ущерб от атаки в предположении о том, что уязвимость в приложении присутствует. Минимизация же ущерба достигается изолированием работы наиболее критичных к выявлению уязвимостей приложений.