Ошибка создания скрипта очистки касперский
Обновлено: 01.07.2024
Благодаря независимым исследователям мы исправили несколько ошибок в наших продуктах.
Мы — разработчики программного обеспечения. То есть мы — люди (по крайней мере пока). А людям свойственно ошибаться. В мире не найдется ни одного разработчика, чье ПО лишено изъянов. Проще говоря, баги случаются, и это нормально.
Требуются охотники за багами
Ненормально другое — не пытаться отлавливать и исправлять эти баги. Поэтому мы стараемся прикладывать к этому значительные усилия. Большая часть уязвимостей в наших продуктах устраняется еще на этапах внутреннего тестирования. Также у нас есть тщательно проработанная программа бета-тестирования, в которой участвует множество людей, включая членов нашего фан-клуба. А еще мы внедрили цикл безопасной разработки. Все это позволяет нам минимизировать количество ошибок и уязвимостей.
Сегодня мы хотели бы поблагодарить независимого исследователя Владимира Паланта, который сообщил нам о нескольких уязвимостях в ряде продуктов. В этом посте мы кратко расскажем о них, о том, как они были исправлены, и о текущем состоянии нашей защиты.
Найдено и исправлено
Чтобы обеспечить безопасность пользователей в Интернете, что среди прочего подразумевает блокировку рекламы и предупреждения о вредоносных результатах поиска, мы используем расширение браузера. Разумеется, вы можете отказаться от установки этого (и любого другого) расширения. Наше приложение не оставит вас без защиты: если оно обнаружит, что расширение не установлено, оно будет внедрять специальные скрипты в посещаемые вами веб-страницы, чтобы с их помощью отслеживать угрозы. В таких случаях между скриптом и телом защитного решения устанавливается канал связи.
Основная часть уязвимостей, обнаруженных Палантом, была именно в этом канале связи. Теоретически, если бы злоумышленник атаковал его, он мог бы попытаться перехватить управление самим приложением. Палант обнаружил эту проблему в Kaspersky Internet Security 2019 в декабре 2018 года и сообщил нам о ней в рамках программы bug bounty. Мы немедленно занялись ее устранением.
Зачем же использовать эти скрипты?
Внедрение скриптов вроде описанных выше — довольно типичная практика в антивирусной индустрии, хотя далеко не все разработчики прибегают к этому методу. Мы используем технологию внедрения скриптов только в том случае, если у пользователя выключено наше расширение браузера. Мы рекомендуем не отказываться от него, но, даже если вы это сделаете, мы все равно будем стоять на страже вашей безопасности.
В основном скрипты служат для повышения комфорта пользователя (например, они помогают блокировать рекламные баннеры). Но еще, например, они защищают от атак с использованием динамических веб-страниц, которые иначе невозможно было бы обнаружить, если расширение Kaspersky Protection выключено. Также на скриптах основана работа таких компонентов, как защита от фишинга и родительский контроль.
Благодаря Владимиру Паланту мы смогли значительно усилить защиту канала связи между скриптами или расширением и основным приложением.
Резюмируя вышесказанное
Мы устранили все обнаруженные уязвимости и значительно сократили поверхность атаки. Наши продукты безопасны – вне зависимости от того, используете вы расширение браузера Kaspersky Protection или нет.
Мы еще раз выражаем признательность всем, кто помогает нам находить ошибки в наших продуктах. Отчасти именно благодаря им наши решения по-прежнему остаются в числе лучших, как подтверждают различные независимые тестирования. Мы приглашаем всех исследователей безопасности принять участие в нашей программе bug bounty.
Ничто не безопасно на 100%. Тем не менее, сотрудничая с исследователями, ликвидируя уязвимости в максимально сжатые сроки и постоянно улучшая наши технологии, мы можем предложить надежную защиту от самых разных угроз.
Как это ни странно, я нашёл на Хабре всего одну статью по данной тематике — и ту в песочнице и сильно незаконченную фактически содержащую в себе маленький кусочек чуть переделанной справки по продукту. Да и Google по запросу klakaut молчит.
Я не собираюсь рассказывать, как администрировать иерархию Kaspersky Security Center (далее по тексту KSC) из командной строки — мне это пока не понадобилось ни разу. Просто хочу поделиться некоторыми соображениями по поводу средств автоматизации с теми, кому это может понадобиться, и разберу один кейс, с которым мне пришлось столкнуться. Если тебе, %habrauser%, эта тема будет интересной — добро пожаловать под кат.
Исторически сложилось так, что в качестве средства антивирусной защиты на работе я предпочитаю продукты Лаборатории Касперского (далее ЛК). Причины и прочие священные войны личных мнений, пожалуй, оставим за кадром.
Естественно, хотелось бы централизованно развернуть, защитить, оградить и не пущать рисовать красивые графики, интегрироваться в существующие системы мониторинга и заниматься прочим перекладыванием работы с больной головы на здоровый сервер. И если с развёртыванием и защитой тут всё более или менее в порядке (у ЛК даже есть какие-то онлайн-курсы по продуктам), то с интеграцией уже сильно грустнее: в последней на текущий момент версии KSC 10.2.434 появилась интеграция аж с двумя SIEM: Arcsight и Qradar. На этом всё.
Для интеграции в что-то своё KSC предоставляет аж 2 интерфейса:
-
: в БД KSC есть ряд представлений с именами, начинающимися на «v_akpub_», из которых можно достать какую-то информацию о состоянии антивирусной защиты. : DCOM-объект, позволяющий скриптовать работу с KSC.
Минусы klakdb очевидны: чтобы напрямую обратиться к БД, нужно иметь к этой БД доступ, что приводит к необходимости лишних телодвижений по созданию правил доступа в межсетевых экранах, настройке прав доступа на серверах СУБД и прочему крайне неувлекательному времяпрепровождению. Ну и плюс мониторинг актуальности всех этих правил, естественно. Особенно интересно становится, когда имеется 20+ серверов — и все в разных филиалах, в каждом из которых свои администраторы.
klakaut в этом плане значительно более интересен: подключившись к корневому серверу иерархии, можно средствами самого KSC пройтись по оной иерархии и получить доступ ко всем нужным данным. Например, построить дерево серверов KSC с пометкой, кто из них живой, а кто нет, позапускать задачи, поперемещать компьютеры и вообще дать волю фантазии.
Минусы тоже есть, естественно: долго и сложно. Если нужно собрать какую-то статистику — нужно будет сначала долго писать скрипт, а потом долго ловить баги ждать, когда он отработает.
Естественно, никто не запрещает (по крайней мере, мне про это неизвестно) использовать оба механизма вместе: например, пройтись по иерархии серверов с помощью klakaut, получить полный список серверов KSC с информацией об используемых БД, а потом уже передать эту информацию в более другие средства автоматизации, которые удалят устаревшие правила из сетевых экранов, создадут новые, дадут разрешения на доступ и принесут кофе в постель отредактируют список источников данных в вашей системе мониторинга, которая, в свою очередь, опросит список и, обнаружив какие-нибудь девиации, с помощью klakaut сделает что-нибудь хорошее. Ну, или просто зарегистрирует инцидент в трекере. Тогда что-нибудь хорошее сделают администраторы в ручном режиме.
Воодушевлённый всеми этими соображениями, я написал свой первый скрипт:
И запустил его на сервере:
Если использовать js, эта ошибка не возникает. Интересно, почему.Открыв консоль KSC, я убедился, что с правами у меня всё в порядке.
К сожалению, KSC не логирует неудачные попытки входа. Переписка с вендором показала, что логирование неудачных попыток входа можно включить (это была отдельная увлекательная история, которая, кстати, ещё не закончилась), однако данная конкретная попытка в логи всё равно попадать отказалась.
Казалось бы, можно сделать вот так:
В этом случае никаких ошибок не будет, но указывать логин с паролем открытым текстом в скрипте мне не показалось замечательной идеей. Новая переписка с техподдержкой ЛК подарила мне следующую рекомендацию:
Необходимо выставить в настройках COM, на вкладке Default Properties:
Default Authentication Level: Packet
Default Impersonation Level: Delegate
Эта инструкция заставила работать исходный скрипт, но показалась мне сомнительной в плане безопасности, поэтому я решил покопать чуть глубже. После некоторого времени поисков нашёлся добрый человек, который подсказал мне, как задать указанные уровни проверки подлинности и олицетворения для конкретного объекта, а не разрешать всем и всё сразу:
Вот так скрипт никаких ошибок выдавать не стал. Первый квест пройден.
Вообще в боевой среде неплохо бы проверять при вызове EnableImpersonation возвращаемое значение на предмет ошибок, а не перенаправлять его в никуда, как это сделал я.Следующая задача: получить от KSC данные об используемой БД.
А вот тут всё сложно: документация о том, как это сделать, молчит. Исследование класса KlAkProxy ничего интересного не выявило, кроме параметра KLADMSRV_SERVER_HOSTNAME, который оказался идентификатором компьютера, на котором установлен KSC.
Перейдём тогда к компьютеру, для этого есть специальный класс KlAkHosts2. Для сокращения количества кода приведу только содержимое блока try:
Обратите внимание: переменная $Params, которую я использовал при подключении к KSC — экземпляр класса KlAkParams. А переменная $HostParams при, на мой взгляд, аналогичной функциональности, является экземпляром класса KlAkCollection. Почему используются разные классы — боюсь даже представить. Видимо, то, что SetAt принимает первым аргументом только целочисленные значения — очень принципиальный момент.
Данный код вернул значение «KSC», а значит, я на верном пути.
Метод GetHostInfo класса KlAkHosts2 достаточно хорошо задокументирован, но — не содержит нужной мне информации. Увы и ах. Зато есть метод GetHostSettings. Всё описание для которого сводится к следующему:
Давайте, заглянем внутрь:
Пробежавшись глазами по названиям секций, я решил просмотреть 85 и 87, поскольку остальные на нужное мне были не очень похожи.
Секция 85, судя по всему, отвечает за события и ныне нам неинтересна. А вот в 87 есть что-то, на что стоит обратить внимание:
Тут я воспользовался одним из предыдущих кейсов, где упоминалось, что нужные данные следует брать именно из KLSRV_CONNECTION_DATA (тогда я ещё не знал, что это вообще такое, просто отложилось).
Ну, вот, в общем-то, и всё. Данные об используемой БД получены. Квест пройден.
Наверное, ещё неплохо бы набросать скрипт для прохождения по иерархии серверов. Здесь ничего загадочного не оказалось, всё было вполне по документации. Я написал скрипт, который выбирает UID родителя, UID самого сервера, экземпляр СУБД и имя БД и выводит их в stdout через разделитель.
Стенд маленький, поэтому результат оказался не очень впечатляющим:
Естественно, чтобы превратить точку в актуальное имя сервера, придётся поколдовать с KlAkHosts2.GetHostInfo(), но это уже не столь страшно, просто ещё сколько-то кода.
Техподдержка ЛК, естественно, пугала меня тем, что структура SS_SETTINGS в следующих релизах KSC может поменяться, поэтому так лучше не делать. К сожалению, даже мой внутренний перфекционист считает, что скрипт нельзя просто написать и забыть: при смене версии используемого ПО его по-любому придётся тестировать и отлаживать. Так что пока пользуемся тем, что есть, а проблемы будем решать по мере поступления, благо, техника уже отработана.
Читайте также: