Не прошло и года как даже НКЦКИ предупредил пользователей о потенциальной опасности браузерных расширений. В связи с известными событиями и возросшей угрозой атак российским пользователям рекомендовали отказаться, или хотя бы минимизировать установку плагинов в браузеры.
Например, НКЦКИ рассказал о вреде аддона «картинка в картинке»: через это расширение, по данным ведомства, проходят массированные кибератаки на российские информационные системы. И если одни аддоны пробивают бэкдоры для хакеров, то другие неплохо справляются сами: вычитывают пароли и логины, платежные данные, метаданные с устройства – одним словом, шпионят – а то и вовсе несут в себе вредоносный код, который включает устройство в ботнет или заражает шифровальщиками и прочим ВПО.
Если без шуток, предупреждение НКЦКИ как минимум не лишнее. Другой вопрос, что проблема этого «слона в комнате» была на повестке задолго до турбулентности в геополитике. Например, в позапрошлом году исследователи обнаружили самую масштабную в Google Chrome кампанию по установке шпионского ПО. Пользователи скачивали вредоносы вместе с различными расширениями для браузера, всего прошло более 32 млн загрузок.
Кстати, в том же 2020-м и у меня про возможность контроля браузерных расширений спросили на одном из весенних вебинаров. Тогда ответ вылился в «записки сумасшедшего», описывающие несколько способов. И вот, подобно смотрящему на часы коту из мема «Пора», настало время поделиться наработками. Надеюсь, они вам будут полезны.
Зачем контролировать аддоны в браузере?
Аддоны/плагины/дополнения/расширения – это небольшие программы, расширяющие стандартные возможности браузера. Например, есть плагины, позволяющие скачивать музыку из соцсетей. Подобно магазинам приложений для смартфонов, для браузеров также существуют свои «магазины». И, как и в случае с App Store и Google Play, «родительская» компания не гарантирует безвредность приложений. Ещё можно сначала сделать «хорошее» дополнение, а потом, когда наберётся аудитория, добавить нехороший функционал. Ведь часто пользователи не меняют настроек по умолчанию и соглашаются на автоматическое обновление.
Есть и другие сценарии. Так или иначе, «плохой» аддон может представлять реальную угрозу безопасности компании,ведь через браузер сегодня можно построить практически всю работу офисного сотрудника. Поэтому штатному ибэшнику должно быть дело, какие аддоны устанавливают пользователи.
Как это сделать?
Задачу контроля за аддонами можно разделить на две подзадачи: работа с теми, у кого они уже установлены; работа по недопущению установки. Начнём по порядку.
Итак, сперва надо выявить пользователей, у которых уже есть аддоны. Затем, в идеале, – выяснить, что это за дополнения, насколько они полезны и нужны. После чего все плохие\ненужные заблокировать или удалить.
Я решил справляться с задачами с помощью DLP и DCAP-системы, потому что именно они были под рукой. Не исключено, что существуют отдельные инструменты для конкретно этой проблемы, но разбираться было лень и вообще причины моего выбора скорее объясняет «лошадь в ванне с огурцами.jpg».
Выявляем тех, у кого установлены аддоны
Приведённые ниже способы ранжировались по удобству, возможностям автоматизации и полноте получаемой информации от «just for lulz» до нормальных рабочих. В качестве подопытного браузера будет выступать Mozilla Firefox. Для эксперимента вооружался DLP-системой «СёрчИнформ КИБ».
Вариант 1
При установке дополнений в русскоязычной версии Firefox в перехвате КИБ (модуля ProgramController) в заголовке окна будет надпись: «* - Mozilla Firefox». Поиск можем провести следующим образом:
В качестве источника данных выбираем «ProgramController». В атрибутах канала выбираем «Заголовок». В качестве значения пишем «Mozilla Firefox». При таком поиске стоит уделять внимание тем результатам в выдаче, в которых процесс/сайт указан «странно». На скриншоте последние три строки являются установкой нового расширения.
Плюсы:
Не замечено.
Минусы:
Нет автоматизации. Поиск руками.
Искать «подозрительные» строки надо глазами.
На выходе можем только сделать выводы о наличии аддона. Что за аддон, понять нельзя.
Способ работает, только если на момент установки расширения на машине пользователя уже стоял агент DLP-системы.
Вывод: Полезность способа сомнительна. Just for lulz.
Вариант 2
С помощью модуля Keylogger. Подойдёт при поиске какого-либо определённого аддона. Допустим, что мы ищем, кто установил расширение «Еasyload». На скриншоте показан запрос и результат:
В качестве источника данных выбран «Keylogger». В качестве алгоритма – «Поиск фразы». Если название аддона состоит из нескольких слов, понадобится дополнительно использовать опции фразового поиска.
Плюсы:
Найдём тех, кто искал конкретный аддон.
Минусы:
Нет автоматизации. Поиск руками.
Способ не работает, если дополнение было установлено до того, как поставили агент DLP-системы.
Можем часть инцидентов пропустить, если пользователь «криворук». Например, написал «eaylosd», потом понял, что пропустил букву, вернулся (мышкой ли, курсором ли), исправил на «easylosd», понял, что недоисправлял, вернулся, исправил на «easyload».
Вывод: способ работает, но только для конкретной задачи и с рядом ограничений.
Вариант 3
Выбираем источник данных «ProgramController». В поле атрибута «Сайт» вносим «about:addons» либо «addons.mozilla.org». В первом случае мы узнаем обо всех случаях, когда пользователь заходил на страницу дополнений в браузере.
Во втором – когда пользователь искал или устанавливал какие-либо аддоны.
Зная время, когда было совершено действие, можно с помощью кнопки «Переход к модулям» перейти в MonitorController, чтобы увидеть экран конечной точки. Таким образом, можно будет понять, что конкретно сотрудник делал:
Если же MonitorController записывал видео, будет ещё нагляднее (благо, весит такое видео немного, порядка 150 МБ для 8-часового дня).
Плюсы:
Конкретная информация о дополнениях, которую можно получить из MonitorController’a.
Минусы:
Нет автоматизации. Поиск руками.
MonitorController должен записывать видео. В противном случае надо заранее настраивать модуль на снятие скриншотов по событию (посещение страницы about:addons или addons.mozilla.com).
Способ работает, если пользователь что-то делает на указанных страницах. Если же аддоны уже стоят и включены, необходимых данных в перехвате не увидим.
Вывод: способ относительно рабочий, но не учитывает ряд важных нюансов.
Вариант 4
Если на базе DLP есть поддержка e-discovery, то можно использовать этот модуль. Логика проста: можно задать область и объект интереса. То есть перечень компьютеров и имя файла (в данном случае, его расширение). В итоге система по сети притащит все файлы и можно будет посмотреть, на каких машинах они были.
Плюсы:
Наконец-то вкалывают роботы, а не человек. Автоматизация.
Получаем список компьютеров, на которых стоят аддоны.
Получаем информацию вне зависимости от того, взаимодействует пользователь с аддоном или нет.
Минусы:
Не будет понимания, что это за аддон, т.к. файлы имеют «странные» имена (см. Вариант 1).
Забивание гвоздей микроскопом. Система будет гонять трафик по сети, передавая файлы в DLP. Файлы будут занимать место в хранилище. Вот только нам, по сути, это не нужно. Достаточно было бы списка, на каких машинах были найдены файлы. Но e-discovery так не работает.
На этом, в принципе, возможности только DLP заканчиваются. Общий вывод таков: автоматизировать процесс можно только в одном случае, но и в нём есть некоторые ограничения. Остальные способы предполагают ручной труд.
Вариант 5. DCAP приходит на помощь.
На уроках физики в школе я часто слышал наставления учителя о том, что надо внимательно читать условия задачи и правильно ставить вопросы. Они сами подсказывают решение. Если применить этот способ на наш случай, получим следующее. Надо понять, на каких машинах есть аддоны. Но что такое аддон? Для Firefox это, упрощённо, файл с расширением .xpi. К тому же, обычно «лишь бы где» не валяется, и мирно лежит себе в профиле пользователя по конкретному адресу.
Таким образом, получается, что нужен инструмент, который может на жёстком диске пользователя найти файл определённого расширения. Бинго! Это одна из базовых задач для DCAP-систем.
В принципе, для FileAuditor достаточно правила из одного условия: поиск по атрибуту «Имя файла», где в качестве имени задаём «*.xpi». Но можно и конкретизировать место поиска до папки, где локально хранятся компоненты Mozilla.
Получаем правило из двух условий:
Расширение файла .xpi
Папка C:\Users\имя_пользователя\AppData\Roaming\Mozilla\Firefox\Profiles\*
Можно было бы копнуть глубже и искать не в Profiles, а сразу в Extensions (это на два уровня ниже). Но делаем скидку на то, что кто-то мог сделать несколько профилей (например, прочитав этот коммент) – и в каждом профиле своя персонализация и свои аддоны. А нам ведь нужно найти их все. В «чистом» браузере никаких аддонов обычно не установлено. Следовательно, и файлов с расширением .xpi нет.
Кстати
Обратите внимание, что в качестве действия выбран «Аудит». Это как раз, чтобы получить только список и не гонять файлы по сети. Все файлы, подходящие под заданные условия, система промаркирует специальной меткой, по которой можно сразу отфильтровать найденные файлы в Консоли Аналитика или AlertCenter.
Штош… Система отработала и можно посмотреть результаты. В ручном режиме всё красиво.
Но каждую машину смотреть смотрелка устанет. Поэтому проще взять AlertCenter и сразу отсортировать по компьютерам.
В итоге на руках есть список машин, на которых нашлись аддоны. Пожалуй, самое важно, что параметры из этого списка можно передать дальше. Но об этом чуть позже.
Плюсы:
Автоматизация. Да, детка. Вменяемая автоматизация процесса, запуск по расписанию, возможность передавать результаты дальше.
Получаем список компьютеров, на которых стоят аддоны.
Получаем адреса, где лежат аддоны.
Получаем информацию вне зависимости от того, взаимодействует пользователь с аддоном или нет.
Минусы:
Не будет понимания, что это за аддон, т.к. файлы имеют «странные» имена (см. Вариант 1).
Вывод: Если по задаче «найти» этот способ сравним с подходом через e-discovery, то по задаче «и обезвредить» - однозначная победа. Поэтому в моей копилке решение с помощью DCAP на первом месте. Кстати, про обезвредить.
Устраняем проблему
Здесь несколько вариантов развития событий:
закрыть пользователям возможность работать с уже установленными аддонами вообще;
какие-то аддоны запретить, а какие-то оставить рабочими;
запретить ставить новые аддоны.
Посмотрим на способы. Здесь уже ранжирования по эффективности не будет. Только перечисление.
Вариант 1
Самый «лобовой» способ – просто удалить файлы .xpi, которые мы нашли с помощью FileAuditor. Вручную ли, или написав какой-нибудь скрипт для автоматизации процесса. Помните эту картинку?
Способ подойдёт как для варианта «жесточайше запретить и удалить» все дополнения, так и для варианта «хорошие оставим, остальные удалим». Во втором случае надо будет заранее выяснить названия файлов хороших аддонов и модифицировать скрипт, чтобы удалял всё, кроме файлов из списка исключений.
Вариант 2
Можно обойтись и без скриптов, силами самого FileAuditor. Можно создать правило блокировки, которое запретит определённым процессам взаимодействовать с помеченными файлами.
Как видите, опций вагон и маленькая тележка. Нет смысла обозревать их все. Основные параметры для нас – это «Действие», вкладка «Объекты» и вкладка «Метки». Остальное – необязательное украшательство.
Если же надо что-то оставить, а что-то прибить, то понадобится откатиться на пару шагов назад:
Выясняем, какие аддоны хорошие, а какие плохие. Хорошие, напоминаю, известны «поимённо».
Создаём в DCAP-системе новое правило, согласно которому система будет ставить отдельную метку на хорошие аддоны.
Таким образом, хорошие аддоны имеют 2 метки (именную и общую, которая выдавалась чисто за расширение), плохие – 1.
В правилах блокировки создаём разрешающее правило для хороших и запрещающее правило для плохих.
Размещаем правила согласно иерархии. Система идёт по правилам сверху вниз, поэтому правила должны идти от частных к общим.
Вариант 3
А ещё можно поменять права доступа. Хоть вручную, хоть скриптами, не сильно важно.
Файлы останутся на месте «до востребования», но пользователю с ними играть будет нельзя.
В общем, какой бы вариант ни был реализован, для пользователя итог будет один – не работает. А выглядеть это будет примерно так:
Будущее
Разобравшись с делами дня сегодняшнего (установленные аддоны удалены или заблочены), самое время подумать о дне завтрашнем. Безусловно, завтра дно будет, но речь про новые аддоны. С этой проблемой, увы, DCAP, не помощник, если рассматривать теорию. Ведь DCAP отработает по логике: «пользователь поставил аддон – система нашла – пометила – применила правило блокировки». Но хочется-то не блокировки, а предотвращения. Поэтому вновь обратимся к DLP.
Расширения живут по известному адресу: https://addons.mozilla.org. Его-то и стоит внести в правило блокировки HTTPController’a. Понятно, что можно это сделать в куче других мест. Но если вспомнить про гвозди и микроскопы, то сделаем в DLP.
Для взаимодействия с пользователем можно выбрать варианты: не взаимодействовать, перенаправлять на указанную страницу, показать сообщение.
Собственно, и всё. Выводов не будет, а вот на вопросы готов ответить.