[BugTraq] Kaspersky antivirus 6: HTTP monitor bypassing

[fifo]

http://www.securityfocus.com/archive/1/434827/30/0

Kaspersky antivirus 6: HTTP monitor bypassing (http://www.securityfocus.com/archive/1/434827/30/0/threaded) May 22 2006 08:09PM

Kaspersky antivirus 6
Kaspersky internet security 6

www.kaspersky.com

Vulnerable Systems: KAV6, KIS6

Detail:

The vulnerability is caused due to HTTP parsing errors in the HTTP monitor (Kaspersky Web-antivirus).

Any mailicious software on local computer can bypass HTTP virus monitor.

Solution:

There is no known solution.

Exploit code:
...

[DVi]

Ответ на эту глупость дан тут: http://forum.kaspersky.com/index.php?act=ST&f=15&t=14738

[Shu_b]

Обход фильтрации трафика в антивирусе касперского (protection bypass)
security.nnov.ru (http://security.nnov.ru/Mdocument803.html)
Источник: BUGTRAQ
Тип: локальная
Опасность: 4/10
Описание: Локальное приложение может "отключить" фильтр используя системный вызов select с надопустимыми аргументами.
Затронутые продукты:
KASPERSKY:Kaspersky Antivirus 6.0
KASPERSKY:Kaspersky Internet Security 6.0
Оригинальный текст: john_(at)_kak-sam.to, Kaspersky antivirus 6: HTTP monitor bypassing (http://security.nnov.ru/Mdocument803.html) (25.05.2006)

[Sanja]

Причем тут select() :) Когда вся проблема парсера заключается в том что он непонимает когда данные шлются по 1 байту а не буффером целиком ж)

ЗАРАЗА жгет ж)

[aintrust]

Именно select() тут "при чем", т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче! ;)

Что же, однако, мешает http-монитору KAV/KIS проанализировать ответ сервера, который принимается сразу и целиком (т.е. и заголовок http-response, и его тело, содержащее вирус) - известно только разработчику монитора, т.е. DVi. :P Ошибка монитора налицо, т.е. формально john (Евгений Гладких) абсолютно прав, и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки, ссылаясь на то, что монитор проверялся бета-тестерами на большинстве существующих браузеров и даунлоадеров, и что, даже если монитор и пропустит какую-то заразу, то потом эту заразу отловят другие модули KAV/KIS. Никто ведь и не говорил, что это проблема KAV/KIS как цельного продукта! Ссылки на то, что по 80 порту можно пустить собственный протокол или "заксорить" содержимое также неуместны, т.к. в данном случае все соответствует rfc. Возникает вопрос: а зачем вообще KAV/KIS нужен был монитор, предназначенный только для "тепличных" условий - ведь на его разработку и отладку было потрачено время (я, как бета-тестер, прекрасно это помню), да и тормозит он трафик довольно существенно? Это вопрос витал в воздухе с самого начала тестирования 6-й линейки - и, как видим, стоит до сих пор.

[Geser]

Именно select() тут "при чем", т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче! ;)

Что же, однако, мешает http-монитору KAV/KIS проанализировать ответ сервера, который принимается сразу и целиком (т.е. и заголовок http-response, и его тело, содержащее вирус) - известно только разработчику монитора, т.е. DVi. :P Ошибка монитора налицо, т.е. формально john (Евгений Гладких) абсолютно прав, и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки, ссылаясь на то, что монитор проверялся бета-тестерами на большинстве существующих браузеров и даунлоадеров, и что, даже если монитор и пропустит какую-то заразу, то потом эту заразу отловят другие модули KAV/KIS. Никто ведь и не говорил, что это проблема KAV/KIS как цельного продукта! Ссылки на то, что по 80 порту можно пустить собственный протокол или "заксорить" содержимое также неуместны, т.к. в данном случае все соответствует rfc. Возникает вопрос: а зачем вообще KAV/KIS нужен был монитор, предназначенный только для "тепличных" условий - ведь на его разработку и отладку было потрачено время (я, как бета-тестер, прекрасно это помню), да и тормозит он трафик довольно существенно? Это вопрос витал в воздухе с самого начала тестирования 6-й линейки - и, как видим, стоит до сих пор.
Насколько я понимаю монитор нужен для мониторинга работы стандартных браузеров. В стандартных браузерах описанная сируация невозможна. Следовательно проблема реально не существует. Поправьте меня если я не прав.

[Sanja]

>и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки
Ошибку признали, фикс в пути, просто ошибка не такого маштаба как ее описывают Ж)

[Alexey P.]

Насчет "стандартных" и "нестандартных" браузеров - правильнее, имхо, в данном случае говорить о стандартных и "нестандартных" сайтах, ответ же не браузер формирует.
Получается, нечего лазить по "нестандартным" сайтам с таким монитором. Вот только закладка со ссылкой на нестандартный сайт вполне возможна и на вполне себе благопристойных сайтах, это уже проходили и не раз. Последний раз месяца полтора назад проходили, помнится.

ЗЫ: За такой реверс-инжиниринг спасибо сказать бы и дыру залатать. Пока ни того, ни другого, к сожалению.

[Sanja]

>ответ же не браузер формирует.
А на ответ вобще сканнеру чихать Ж) он по запросу протокол определяет

[aintrust]

Насколько я понимаю монитор нужен для мониторинга работы стандартных браузеров. В стандартных браузерах описанная сируация невозможна. Следовательно проблема реально не существует. Поправьте меня если я не прав.
А вы полагаете, что монитор разбирается в том, идет запрос от "стандартного" браузера или от чего-то другого? Нет, конечно же! Монитор просто сканит весь трафик, идущий на/с определенного порта, на наличие сигнатур зловредов. Более того, насколько я понимаю архитектуру KAV/KIS, монитору вообще пофигу, какой там идет протокол и от какого клиента он идет! Вспомните соответствующие настройки в KAV/KIS - вы ведь там не указываете никаких клиентов. Да и указание там названия протокола - это чисто для того, чтобы хоть как-то обозвать. Сканиться все равно будет все подряд, независимо от "указанного вами" протокола для данного порта.

По поводу того, возможно ли такая ситуация в стандартных браузерах - вопрос, конечно, интересный. Точно такая, как в эксплойте, - скорее всего нет, но похожая (когда запрос, к примеру, отправляется "кусочками" или ответ принимается "кусочками") - да. И как в этом случае отреагирует монитор - я не знаю, может быть тоже "никак"!

Мне, например, не понятно, почему монитор не отлавливает ситуацию, описанную в эксплойте - он должен это делать! Т.е. реально мы имеем дело с небольшим багом монитора, который просто не был до этого отловлен. И, безусловно, он совсем не стоит той шумихи, что вокруг него подняли!

[aintrust]

>и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки
Ошибку признали, фикс в пути, просто ошибка не такого маштаба как ее описывают Ж)
Не видел я этого признания, может быть пропустил. Видел только то, что DVi назвал сообщение об уязвимости "глупостью" несколькими постами выше, с чем я совершенно не могу согласиться. Баг имеет место - это надо было просто признать и поскорее исправить, а не заниматься препирательствами с john-ом, кто лучше/хуже знает RFC.

Насчет "масштаба ошибки" - согласен, и классификация ее опасности как 4/10 мне кажется даже завышенной. Учитывая тот факт, что KAV/KIS - это комплексный продукт, где компоненты помогают и дополняют друг друга, можно сказать, что реальной опасности для пользователя в данном случае нет никакой.

[Sanja]

На официальном сайте пресс-релиз

[aintrust]

"И это - правильно!" ;)

[orvman]

aintrust,
Ссылки на то, что по 80 порту можно пустить собственный протокол или "заксорить" содержимое также неуместны Ес-но, какой еще протокол на уровне приложений и т.д.? Это вообще не то совсем
т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче! А вот тут Вы меня удивляете. Я знаю и читал Ваши посты на многих Форумах т.к. Человек Вы известный, но эта цитата неприминима, согласно, опять же, упомянутыми Вами RFC, угадайте как передаются данные IP? Я согласен с Вами, просто неточности есть в Ваших словах.
Sanja,
А на ответ вобще сканнеру чихать Ж) он по запросу протокол определяет нет, конечно-же. При чем тут такая цитата? Насколько я понимаю, был запрос и неважно куда - на http или ftp и т.д. - только пришел первый же ответ (исключение UDP) - после сбора пакетов он (целый) тут же должен сканиться.

[aintrust]

...
А вот тут Вы меня удивляете. Я знаю и читал Ваши посты на многих Форумах т.к. Человек Вы известный, но эта цитата неприминима, согласно, опять же, упомянутыми Вами RFC, угадайте как передаются данные IP? Я согласен с Вами, просто неточности есть в Ваших словах.
...

"Слово произнесенное есть ложь!" Знаем-знаем... :P

А что конкретно вы имеете ввиду? Какую именно неточность вы увидели в моей фразе? И зачем мне нужно "гадать, как передаются данные IP" - мне уже лет 20 примерно кажется, что я это знаю... ;)

[Sanja]

>нет, конечно-же. При чем тут такая цитата?
Если вы невкурсе как работает протоколлер кава то это ваши личные трудности Ж) Перед тем как возмущатся надо бы наверное ознакомится с предметом Ж)

[DVi]

Ого, какая дискуссия развернулась - я думал, что только на форуме ЛК, да на anti-malware эту тему обсасывают :)

Теперь по существу.
Как сказал Саня, ошибку мы признали, и это ни для кого не является секретом. Хотя ошибка эта из ряда "а чего это вы использовали оператор = вместо += ?", т.е. без практического смысла вообще. Т.е. что до ее исправления, что после оного - ничего в безопасности пользователя не изменится, кроме морального удовлетворения "неизвестного исследователя" Евгения Гладких.
Далее, aintrust, Вы утверждаете, что опасна побайтная передача _с_сервера_ , а описанная "уязвимость" утверждает, что опасна побайтная передача _с_клиента_ . Чувствуете разницу? В первом случае возможно размещение иксплоита на сервере (а это действительно опасно, особенно если такие данные без проблем вытягиваются браузером), во втором - необходим его запуск на локальном компьютере (а вот с этим запуском, как я сказал, борются совсем другие компоненты защиты: файрволл, проактивка и файловый антивирус).
На anti-malware.ru Бубермот проводил подробные исследования.

Да, и еще: мне стала понятна причина публикации этой "уязвимости". Дело в том, что текущая бета DrWeb SpiderGate тоже не обрабатывает побайтный запрос к серверу. Стало быть, Евгений Гладких просто проверяет собственные баги на продукте ЛК.
Я еще не понял, что у него творится с логикой - ведь любые его пассажи на тему необходимости проверки HTTP (а именно: разговор про пресловутые wmf-иксплоиты, борьба с которыми в кеше браузера бесполезна, т.к. картинки сначала исполняются в процессе браузера. а лишь потом дампируются в кеш) разбиваются об отсутствие таковой защиты в продуктовой линейке DrWeb. Я бы понял еще, если б этот разговор пошел после релиза SpiderGate, а так - это какой-то детсад.



Видел только то, что DVi назвал сообщение об уязвимости "глупостью" несколькими постами выше, с чем я совершенно не могу согласиться. Баг имеет место - это надо было просто признать и поскорее исправить, а не заниматься препирательствами с john-ом, кто лучше/хуже знает RFC.

Действительно, слово "уязвимость" в данном контексте есть глупость. Ибо "уязвимость" и "баг", мягко говоря, не синонимы.
Надеюсь, Вы обратили внимание, я не занимаюсь "препирательством, кто лучше/хуже знает RFC" (другое название: не меряюсь _сами_знаете_чем_). Размер своей компетенции я знаю, и он меня (и моего работодателя) вполне удовлетворяет.

Спасибо за дискуссию. Добро пожаловать на http://forum.kaspersky.com

[aintrust]

Далее, aintrust, Вы утверждаете, что опасна побайтная передача _с_сервера_ , а описанная "уязвимость" утверждает, что опасна побайтная передача _с_клиента_ .
Вы ничего не путаете? :P Приведите, если не трудно, мою фразу, где я это утверждаю! Да и не мог я написать, что "опасна побайтная передача _с_сервера_ ", т.к. я ее вообще не рассматривал - да и кому она, собственно, опасна? ТрафикМонитору? Браузеру? Я не понял...

"Эксплойт" передает http-запрос побайтно, но ответ сервера при этом принимается целиком. Что мешает (мешало) вашему трафикМонитору проанализировать этот ответ (в котором, собственно, и находится код вируса)? Насколько я понимаю - только то, что изначально вы парсите запрос к серверу, который был подан вам "в разобранном виде", но вы его просто не собрали (или неправильно собрали, или вообще не собирали - не знаю) перед анализом и принятием решения о том, какого рода трафик идет на сервер, поэтому и последующий ответ сервера проигнорировали. Я написал именно это - и ничего более. Это баг? Конечно же да - да вы и сами это подверждаете. ;)

Насчет остального - я полагаю, что нет смысла продолжать дискуссию, все уже вроде и так всем ясно.

[DVi]

Извините, я спутал Ваше сообщение с сообщением Алексея Подтопалова. Вы действительно компетентны в данном вопросе. Ошибка, допущенная в парсере, заключалась именно в отсутствии детекта протокола - отсюда и отсутствие разбора протокола.

[aintrust]

ОК, спасибо за разъяснение!