Как отправить отчет доктор веб
Обновлено: 07.07.2024
Данная статья написана в рамках ответственного разглашения информации о уязвимости. Хочу выразить благодарность сотрудникам Dr.Web за оперативное реагирование и исправление обхода брандмауэра (firewall).
В этой статье я продемонстрирую обнаруженную мной возможность обхода брандмауэра (firewall) в продукте Dr.Web Security Space 12 версии.
При исследовании различных техник и методик обхода антивирусных программ я заметил, что Dr.Web Security Space 12 версии блокирует любой доступ в Интернет у самописных приложений, хотя другие антивирусные программы так не реагируют. Мне захотелось проверить, возможно ли обойти данный механизм безопасности?
Разведка
Во время анализа работы антивирусной программы Dr.Web, я обнаружил, что некоторые исполняемые файлы (.exe), в папке C:\Program Files\DrWeb, потенциально могут быть подвержены Dll hijacking.
Dll Hijacking — это атака, основанная на способе поиска и загрузки динамически подключаемых библиотек приложениями Windows. Большинство приложений Windows при загрузке dll не используют полный путь, а указывают только имя файла. Из-за этого перед непосредственно загрузкой происходит поиск соответствующей библиотеки. С настройками по умолчанию поиск начинается с папки, где расположен исполняемый файл, и в случае отсутствия файла поиск продолжается в системных директориях. Такое поведение позволяет злоумышленнику разместить поддельную dll и почти гарантировать, что библиотека с нагрузкой загрузится в адресное пространство приложения и код злоумышленника будет исполнен.
Например, возьмём один из исполняемых файлов – frwl_svc.exe версии 12.5.2.4160. С помощью Process Monitor от Sysinternals проследим поиск dll.
Однако, у обычного пользователя нет разрешений для того чтобы подложить свой DLL файл в папку C:\Program Files\DrWeb. Но рассмотрим вариант, в котором frwl_svc.exe будет скопирован в папку под контролем пользователя, к примеру, в папку Temp, а рядом подложим свою библиотеку version.dll. Такое действие не даст мне выполнение программы с какими-то новыми привилегиями, но так мой код из библиотеки будет исполнен в контексте доверенного приложения.
Подготовительные мероприятия
Я начну свой эксперимент с настройки двух виртуальных машин с Windows 10. Первая виртуальная машина служит для демонстрации пользователя с установленным антивирусом Dr.Web. Вторая виртуальная машина будет «ответной стороной», на ней установлен netcat для сетевого взаимодействия с первой виртуалкой. Начальные настройки при установке:
На первую виртуальную машину с IP 192.168.9.2 установлю Dr.Web последней версии, в процессе установки Dr.Web’а выберу следующие пункты:
На вторую виртуальную машину с ip 192.168.9.3 установлю netcat.
Для демонстрации я разработал два исполняемых файла:
Второй файл — это прокси-библиотека version.dll, которая размещается рядом с frwl_svc.exe на первой виртуальной машине. Функциональность та же, что и test_application.exe, только код собран как dll.
Видео эксплуатации
После подготовительных мероприятий, я, наконец, подошёл к эксплуатации. На этом видео представлена демонстрация возможности обхода брандмауэра (firewall) в продукте Dr.Web Security Space 12 версии. (Dr.Web, version.dll и test_application.exe находится на первой виртуальной машине, которая расположена с левой стороны видео. А netcat находится на второй виртуальной машине, которая расположена с правой стороны видео.)
Вот что происходит на видео:
На второй виртуальной машине запускаем netcat он же nc64.exe и прослушиваем порт 4444.
Затем на первой виртуальной машине в папке C:\Users\root\AppData\Local\Temp распакуем aplications.7z, там находятся version.dll и test_application.exe.
После этого, с помощью whoami показываем, что все действия от обычного пользователя.
Потом копируем C:\Program Files\DrWeb\frwl_svc.exe в папку C:\Users\root\AppData\Local\Temp\aplications.
Дальше демонстрируем, что брандмауэр (firewall) включён, исключения отсутствуют и время последнего обновления антивируса.
Следующим шагом запускаем тестовое приложение test_application.exe и проверяем работоспособность брандмауэр (firewall). Dr.Web заблокировал тестовое приложение, а значит можно сделать вывод, что брандмауэр (firewall) работает корректно.
Запускаем frwl_svc.exe и видим подключение в nc64.exe на второй машине.
Передаём команду на создание папки test на первой машине с помощью nc64.exe, который находится на второй машине.
Вывод
Убедившись, что способ работает, можно сделать предположение, что, антивирус доверяет «своим» приложениям, и сетевые запросы, сделанные от имени таких исполняемых файлов, в фильтрацию не попадают. Копирование доверенного файла в подконтрольную пользователю папку с готовой библиотекой — не единственный способ исполнить код в контексте приложения, но один из самых легковоспроизводимых. На этом этапе я собрал все артефакты исследования и передал их специалистам Dr.Web. Вскоре я получил ответ, что уязвимость исправлена в новой версии.
Проверка исправлений
Вижу, что frwl_svc.exe версии 12.5.3.12180 больше не загружает стандартные dll. Это исправляет сам подход с dll hijacking, но появилась гипотеза, что логика работы с доверенными приложениями осталась. Для проверки я воспользовался старой версией frwl_svc.exe.
Подготовительные мероприятия
Начну проверку своей гипотезы с того, что настрою две виртуальные машины с windows 10 по аналогии с тем, как всё было в демонстрации.
На первую виртуальную машину с ip 192.168.9.2 я установлю Dr.Web последней версии. Процесс установки Dr.Web не отличатся от того, который был описан в предыдущем отчёте. А также в папку Temp я скопирую frwl_svc.exe версии 12.5.2.4160 и version.dll из предыдущего отчета.
На вторую виртуальную машину c ip 192.168.9.3 я установлю netcat.
Видео эксплуатации
После настройки двух виртуальных машин пришло время эксплуатации. На этом видео показана возможность обхода патча, которым Dr.Web исправил ошибку из предыдущего отчёта. Расположение виртуальных машин не отличается от представленных в предыдущем видео. Напомню, первая машина находится с левой стороны на видео, а вторая машина – с правой стороны. Действия в видео:
На второй виртуальной машине запускаем netcat(nc64.exe) и прослушиваем порт 4444.
Затем на первой виртуальной машине с помощью whoami показываем, что все действия от обычного пользователя.
Потом показываем версию frwl_svc.exe (12.5.2.4160) в папке C:\Users\drweb_test\AppData\Local\Temp.
Дальше демонстрируем версию frwl_svc.exe (12.5.3.12180) в папке C:\Program Files\DrWeb.
Следующим шагом показываем, что брандмауэр (firewall) включён, исключения отсутствуют и время последнего обновления.
После этого запускаем C:\Users\drweb_test\AppData\Local\Temp \frwl_svc.exe и видим подключение в nc64.exe во второй машине.
Последним шагом передаём команду на создание папки test на первой машине с помощью nc64.exe, который находится на второй машине.
Бывает иногда. В данном случае тебе дали возможность попробовать конкурента)) Каспер?
когда у меня попросили емайл и фио, я тут же закрыл эту страницу
прощай курейт, видимо и туда просочились эффективные менеджеры
Я проверил, мне пришло за пару минут. Скинуть ссылку?)))
Да, стало намного неудобнее, но, как правило, ссылка приходит. Скорее всего, дело в почте.
Да! На днях буквально с той же проблемой столкнулся. Самый ахтунг- за курейтом бежишь, когда уже приспичило.. Тоже не дождался. AVZ, AdwCleaner теперь в помощь.
Раньше удобнее было конечно, но мне позавчера пришло за пару минут и порядок.
В энциклопедии, напротив определения "максимально бесполезная хуйня",
должна быть именно эта картинка
Жизнь становится лучше. Правда?
Ростелеком и Dr.WEB. Месяц отсутствия услуги! 8 раз меня послала техподдержка по СМС!
Я много слышал про Ростелеком. Не верил. Проблем не было. До 24 января.
24 января я решил купить у Ростелекома за сгорающие бонусы антивирус Dr.Web. В личном кабинете появилась такая прекрасная информация:
На самом деле Ростелеком продает не сам антивирус, а Dr.Web AV-desk - интернет-сервис для предоставления провайдерами комплекса услуг по информационной защите в режиме онлайн.
При первой установке авторизация прошла успешно. Но на последнем этапе зависла, пришлось ее отменить. Установка корректно отменилась.
Но при повторной установке авторизацию вшитый ключ категорически не проходил. Вообще никак.
Теперь самое интересное.
1. В тот же день 24 января я оформил заявку на тех поддержку 95855882.
2. 2 февраля, так и не увидев решения проблемы, перезвонил в тех поддержку. Оказалось, что заявка 95855882 закрыта. Мной была оставлена претензия на закрытие заявки - 96732173. (По ней 3 февраля начислили 100 рублей, хотя проблема решена не была).
3. Тогда же 2 февраля мне оформили повторную заявку 96359192.
4. 9 февраля мне пришло СМС о том, что заявка 96359192 выполнена и закрыта. Была приложена ссылка по которой я якобы мог подтвердить решение вопроса (ссылка не работала). Надо ли говорить, что проблема не была решена и со мной никто не связался?
4. Тут же 9 февраля я оформил претензию по повторному закрытию заявки - 96732173. (11 февраля по ней начислили 100 рублей, проблема так и не решена).
5. 11 февраля мне вновь пришло смс о закрытии 96359192 в 21:11. Я связался со старшим смены тех поддержки. Он вновь открыл заявку 96359192 и создал новую претензию о том, что заявка была закрыта без решения и обратной связи - 96863904.
6. Однако, уже в 21:49 11 февраля мне пришло смс об очередном закрытии заявки 96359192! Я вновь связался со страшим смены тех поддержки. Это уже был другой человек. Она вновь открыла заявку 96359192.
7. Уже через несколько минут после окончания разговора с оператором заявка 96359192 вновь была закрыта в 22:25! Я вновь связался со старшим смены тех поддержки. Она сказала мне, что опять открыла заявку и поставила ее на контроль!
8. 12 февраля я решил узнать статус заявки 96359192. Связался со старшим смены. Оказалось, что заявка ОПЯТЬ закрыта. Причем окончательно и открыть ее нельзя. А на контроль они ничего не ставят!! Мне оформили новую заявку 96908406.
9. 14 февраля пришло смс по претензии 96863904 о том, что они передали всю информацию руководителю подразделения. Как позже узнал, на этом претензия была закрыта.
10. 15 февраля пришло СМС, что заявка 96908406 снова закрыта! Я вновь связался с тех поддержкой и они возобновили заявку. Также была оформлена очередная претензия по ситуации регулярных закрытий заявок - 97051015.
11. 21 февраля пришло СМС, что заявка 96908406 закрыта очередной раз! Я связался со старшей смены. Она вновь открыла заявку и оформила очередную претензию - 97364034
Параллельно с этим я пытался что-то сделать в официальном сообществе в ВК. Все, что они могли - рекомендовали ждать решения проблемы.
Резюме: заявки на тех поддержку по этому вопросу были (на сегодняшний день) закрыты 8 раз: 95855882 - 1 раз, 96359192 - 5 раз, 96908406 - 2 раза.
Ни разу со мной никто даже не связался хотя бы.
Таким образом, я не могу использовать услугу с 24 января. Вообще. Никак.
Я вообще в шоке от происходящего. Какой-то троллинг и издевательство, в расчете таким образом дотянуть до окончания действия услуги - 25 марта.
Ну и полная некомпетентность. Неспособность решить элементарную проблему авторизации ключа.
Мне уже поднадоел этот "боулинг" с заявками. Активно думаю о переводе вопроса в юридическую плоскость.
Может Dr.Web мог бы помочь своим клиентам (Ростелекому) решить этот вопрос?? Так не обращается Ростелеком к ним за помощью. Сам Dr.Web к этому отношения не имеет, вся авторизация проходит на серверах Ростелекома.
13. 24 февраля в 10:27 заявка 96908406 снова была закрыта! Через 6 минут!
14. Я связался со старшей смены, она возобновила заявку, но через пару минут в 13:57 заявка 96908406 опять была закрыта!
15. Я направил логи через чайт на сайте, там возобновили снова заявку 96908406. В вк выяснил, что на меня открыли еще заявку 97364034.
16. Связался с департаментом внешних коммуникаций Ростелекома с ссылкой на этот пост. Обещали передать проблему "руководству профильного блока"
Подитог. Заявка 96908406 была закрыта 4 раза. Всего заявки по этой проблеме были закрыты 10 (ДЕСЯТЬ. ) раз.
Читайте также: