Комментарии 42
Отчет об уязвимости был отправлен в Доктор Веб и, вроде бы, разработчики все поправили.
А Премию выписали?
Или большое спасибо?
Просто поблагодарили
Ходят слухи, что в некоторых организациях «спасибо» должен говорить специалист, который нашёл брешь. За то, что через месяц в суд не подадут, хоть прошлые отношения и были с рукопожатиями.
Лицензионное соглашение Dr.Web Security Space 12.0:
Лицензионное соглашение Dr.Web Security Space 12.0:
9. Пользователю не разрешается без письменного согласия Правообладателя изменять, декомпилировать, дизассемблировать, дешифровать и производить иные действия с объектным кодом ПО, в том числе имеющие целью получение информации о реализации алгоритмов и принципов, используемых в ПО, за исключением случаев, прямо предусмотренных действующим законодательством Российской Федерации.
Это какое-то очень странное лицензионное соглашение для антивируса. Злоумышленники данное положение явно не будут исполнять.
Законодательство РФ позволяет пользователю декомпилировать и модифицировать ПО для улучшения его характеристик(несколько спорный момент, т.к. «сделать триал не 30 дней а 300000 дней» тоже впринципе улучшение характеристик), однако делиться полученными результатами уже нельзя.
По идее попытка устранение косяка с обходом подписи вполне себе попадает в это разрешение.
По идее попытка устранение косяка с обходом подписи вполне себе попадает в это разрешение.
Да уж. Надо быть осторожнее. А может отказаться от использования такого ПО, а использовать либо свободное (в том числе и антивирусы) или самописное?!
Можно получить дистрибутивный комплект программы или даже распакованные файлы без согласия с eula — раз
Два — в такой формулировке явно, что пункт противоречит з-у РФ и следовательно можно все разбирать. Более того, там в тексте eula имеется определение того, что же такое "объектный код"? Если нет, то вообще пункт ни о чем
P.s. согласен с JerleShannara
https://www.consultant.ru/document/cons_doc_LAW_64629/3cbc9e0590122df6ade6baf1d39f9ee34411c24a/
ГК РФ Статья 1280. Право пользователя программы для ЭВМ и базы данных
3'. Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения воспроизвести и преобразовать объектный код в исходный текст (декомпилировать программу для ЭВМ) или поручить иным лицам осуществить эти действия, если они необходимы для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой, при соблюдении следующих условий:
1) информация, необходимая для достижения способности к взаимодействию, ранее не была доступна этому лицу из других источников;
2) указанные действия осуществляются в отношении только тех частей декомпилируемой программы для ЭВМ, которые необходимы для достижения способности к взаимодействию;
3) информация, полученная в результате декомпилирования, может использоваться лишь для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, не может передаваться иным лицам, за исключением случаев, когда это необходимо для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, а также не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ, или для осуществления другого действия, нарушающего исключительное право на программу для ЭВМ.
Ну если придираться к словам, то автор статьи и не взаимодействовал напрямую с кодом никаким образом, он работал именно что с функциями, которые предоставляет программа пользователю. Как мне кажется *.dll на исходный код программы тянут слабо, как минимум потому, что никак не защищены от редактирования и просмотра пользователем.
Не ставлю себе цели спорить по поводу взаимодействия с ПО автором статьи, но хочу уточнить, что dll точно так же является исполняемым файлом и может быть как угодно защищён. Отличием dll от exe в первую очередь есть интерфейс взаимодействия. В DLL он построен так, что бы была возможность удобно переиспользовать код в другом ПО. При прочих равных DLL редактируются и просматриваются не особо тяжелее, чем EXE.
НЛО прилетело и опубликовало эту надпись здесь
У продуктов Dr.Web есть только два плюса — цена и производительность, остальное как получится.
Сейчас точно не скажу но лет 10 назад по моей практике Дрвеб был лучшим практически по всем параметрам, сейчас стал заметно тормознее и возможно уже не так силен.
Эксплуатировал drweb для почтовых серверов под Linux, дебажить что то и настраивать это боль, даже мониторинг из коробки не завезли, пришлось к zabbix прикручивать, а выяснить по какой конкретно причине письмо было отброшено это тот ещё квест. Я бы понял если бы продукт был open source, но нет это коммерческая разработка.
Вы наверно шутите или практика была не слишком обширная. За годы моей работы в сервисе больше всего зараженных машин к нам приносили именно с dr.web.
Есть еще одна очень полезная вещь для всех «тыжпрограммистов»- Curelt.
Ага, наш зеленый антивирус такой же бесполезный, как и красный, но дешевле и легче.
Вы проделали большой труд! Благодарю! На сколько понимаю, Вы использовали механизм операционной системы, производящий поиск файлов в особом порядке для подмены загрузки «системной» библиотеки. Т.е. данной угрозе подвержены почти все исполняемые файлы (в зависимости от того какие зависимости от системных библиотек у них есть). И при этом от этого достаточно сложно защититься. Вы, случайно, не проводили тесты на остальных известных антивирусных продуктах?
Спасибо. Да, вы верно описали механизм который позволил внедрить свой код в приложение с подписью. В общем смысле, это можно назвать «обратный dll hijack» — мы не dll подкладываем к приложению, а приложение к dll.
В моем понимании от этого нет смысла защищаться — даже если руками в файле прописать все зависимости по полным путям (я проверял — можно прописать полные пути в таблице импорта и все будет работать). Если приложение работает от имени пользователя, то он имеет почти полный контроль над всем, что происходит в адресном пространстве этого приложения. Не было бы возможности подменить dll — поставил бы хук или просто OpenProcess + WriteProcessMemory.
Тут скорее дело в самой архитектуре фон Неймана — подпись хорошо работает если файл рассматривается как данные. Если файл рассматривается как код, то тут уже все печально.
Другие антивирусные продукты я не рассматривал, а среди не антивирусов я подобную проверку встречал в 3 продуктах — во всех сработал обход типа «обратный dll hijack».
В моем понимании от этого нет смысла защищаться — даже если руками в файле прописать все зависимости по полным путям (я проверял — можно прописать полные пути в таблице импорта и все будет работать). Если приложение работает от имени пользователя, то он имеет почти полный контроль над всем, что происходит в адресном пространстве этого приложения. Не было бы возможности подменить dll — поставил бы хук или просто OpenProcess + WriteProcessMemory.
Тут скорее дело в самой архитектуре фон Неймана — подпись хорошо работает если файл рассматривается как данные. Если файл рассматривается как код, то тут уже все печально.
Другие антивирусные продукты я не рассматривал, а среди не антивирусов я подобную проверку встречал в 3 продуктах — во всех сработал обход типа «обратный dll hijack».
В чем разница в подкладывании exe к dll или dll к exe? Это только для обхода ограничений NTFS?
При загрзуке DLL, винда вызовет из ее DllMain и передаст в нее информацию а процессе который загружает dll, из структур prcessinformation или startupinfo можно узначть имя исполняемого файла и путь к нему и проверить у него подпись. Но и сам процесс перед import_DLL может проверить подпись библиотеки, тогда hijackDLL не сработает. В таком случае останется только патчить проверку подписи, и в таком случае подпись исполняемого файла окажется невалидной и о LPE в драйвере можно забыть
При загрзуке DLL, винда вызовет из ее DllMain и передаст в нее информацию а процессе который загружает dll, из структур prcessinformation или startupinfo можно узначть имя исполняемого файла и путь к нему и проверить у него подпись. Но и сам процесс перед import_DLL может проверить подпись библиотеки, тогда hijackDLL не сработает. В таком случае останется только патчить проверку подписи, и в таком случае подпись исполняемого файла окажется невалидной и о LPE в драйвере можно забыть
Типовой сценарий атаки dll hijack подразумевает, что есть некоторое приложение по фиксированному пути, например сервис, который запускается с высокими правами. «Подложив» dll к такому приложению мы получим запуск своего кода с теми же правами.
В таком сценарии нет смысла копировать приложение к dll, поскольку его кроме нас запускать не будет, а значит и права будут те же. Но в случае, как в статье, это дает возможность запускать свой код от имени подписанного бинаря.
В первом сценарии можно рассматривать проверку подписи, но там есть свои особенности, например, загрузка dll происходит до работы основного кода, поэтому нельзя добавить проверку подписи к загружаемым dll из таблицы импорта. А во втором сценарии это все и вовсе бессмысленно — все действия проходят под контролем пользователя и легко динамически правятся.
В таком сценарии нет смысла копировать приложение к dll, поскольку его кроме нас запускать не будет, а значит и права будут те же. Но в случае, как в статье, это дает возможность запускать свой код от имени подписанного бинаря.
В первом сценарии можно рассматривать проверку подписи, но там есть свои особенности, например, загрузка dll происходит до работы основного кода, поэтому нельзя добавить проверку подписи к загружаемым dll из таблицы импорта. А во втором сценарии это все и вовсе бессмысленно — все действия проходят под контролем пользователя и легко динамически правятся.
Надо же, вам Dr.Web даже ответил. У них панель тикетов саппорта на сайте не рабочая, раз 20 пробовал аттач приложить — ошибка. Написал без вложения, так и не ответили.
НЛО прилетело и опубликовало эту надпись здесь
Так странно, крупные компании обычно специально платят деньги, чтобы искали уязвимости, а тут нашли, принесли и ничего
Стандартный windows DLL hell, который используется как во вред, так и во благо (например, старое ускорение Direct3D). Согласен с позицией автора, что подобная программа, как DrWeb должна проверять не только свои цифровые подписи, но и библиотек.
Кстати, а что если эта библиотека будет подписана, но не через DrWeb? Это эксперимент для версии 12 :)
Отличная идея!
Я еще добавлю, что почти наверняка, что в составе Dr.Web есть компоненты уровня драйверов (*.sys), с которыми почти наверняка могут взаимодействовать любые приложения ) и там нет проверки того, что за приложение пытается сделать привилегированный вызов.
На такой глупости уже попадались АСУС и прочие вендоры.
Вроде такого — https://www.secureauth.com/labs/advisories/asus-drivers-elevation-privilege-vulnerabilities
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От комментария на Хабре к уязвимости в антивирусе Dr. Web