[BugTraq] Kaspersky antivirus 6: HTTP monitor bypassing
http://www.securityfocus.com/archive/1/434827/30/0
Kaspersky antivirus 6: HTTP monitor bypassing 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:
...
Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:
Ответ на эту глупость дан тут: http://forum.kaspersky.com/index.php...T&f=15&t=14738
Обход фильтрации трафика в антивирусе касперского (protection bypass)
security.nnov.ru
Источник: 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 (25.05.2006)
Причем тут select()Когда вся проблема парсера заключается в том что он непонимает когда данные шлются по 1 байту а не буффером целиком ж)
ЗАРАЗА жгет ж)
Всего один дурной бит - и гигабайты лежат в маразме.
Скажи мне свою OS и я скажу тебе КТО ты.
Именно select() тут "при чем", т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче!
Что же, однако, мешает http-монитору KAV/KIS проанализировать ответ сервера, который принимается сразу и целиком (т.е. и заголовок http-response, и его тело, содержащее вирус) - известно только разработчику монитора, т.е. DVi.Ошибка монитора налицо, т.е. формально john (Евгений Гладких) абсолютно прав, и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки, ссылаясь на то, что монитор проверялся бета-тестерами на большинстве существующих браузеров и даунлоадеров, и что, даже если монитор и пропустит какую-то заразу, то потом эту заразу отловят другие модули KAV/KIS. Никто ведь и не говорил, что это проблема KAV/KIS как цельного продукта! Ссылки на то, что по 80 порту можно пустить собственный протокол или "заксорить" содержимое также неуместны, т.к. в данном случае все соответствует rfc. Возникает вопрос: а зачем вообще KAV/KIS нужен был монитор, предназначенный только для "тепличных" условий - ведь на его разработку и отладку было потрачено время (я, как бета-тестер, прекрасно это помню), да и тормозит он трафик довольно существенно? Это вопрос витал в воздухе с самого начала тестирования 6-й линейки - и, как видим, стоит до сих пор.
Насколько я понимаю монитор нужен для мониторинга работы стандартных браузеров. В стандартных браузерах описанная сируация невозможна. Следовательно проблема реально не существует. Поправьте меня если я не прав.Сообщение от aintrust
Именно select() тут "при чем", т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче!
Что же, однако, мешает http-монитору KAV/KIS проанализировать ответ сервера, который принимается сразу и целиком (т.е. и заголовок http-response, и его тело, содержащее вирус) - известно только разработчику монитора, т.е. DVi.
>и не совсем понятно, почему DVi (Виталий Денисов) не хочет признать наличие ошибки
Ошибку признали, фикс в пути, просто ошибка не такого маштаба как ее описывают Ж)
Всего один дурной бит - и гигабайты лежат в маразме.
Скажи мне свою OS и я скажу тебе КТО ты.
Насчет "стандартных" и "нестандартных" браузеров - правильнее, имхо, в данном случае говорить о стандартных и "нестандартных" сайтах, ответ же не браузер формирует.
Получается, нечего лазить по "нестандартным" сайтам с таким монитором. Вот только закладка со ссылкой на нестандартный сайт вполне возможна и на вполне себе благопристойных сайтах, это уже проходили и не раз. Последний раз месяца полтора назад проходили, помнится.
ЗЫ: За такой реверс-инжиниринг спасибо сказать бы и дыру залатать. Пока ни того, ни другого, к сожалению.
>ответ же не браузер формирует.
А на ответ вобще сканнеру чихать Ж) он по запросу протокол определяет
Всего один дурной бит - и гигабайты лежат в маразме.
Скажи мне свою OS и я скажу тебе КТО ты.
А вы полагаете, что монитор разбирается в том, идет запрос от "стандартного" браузера или от чего-то другого? Нет, конечно же! Монитор просто сканит весь трафик, идущий на/с определенного порта, на наличие сигнатур зловредов. Более того, насколько я понимаю архитектуру KAV/KIS, монитору вообще пофигу, какой там идет протокол и от какого клиента он идет! Вспомните соответствующие настройки в KAV/KIS - вы ведь там не указываете никаких клиентов. Да и указание там названия протокола - это чисто для того, чтобы хоть как-то обозвать. Сканиться все равно будет все подряд, независимо от "указанного вами" протокола для данного порта.
По поводу того, возможно ли такая ситуация в стандартных браузерах - вопрос, конечно, интересный. Точно такая, как в эксплойте, - скорее всего нет, но похожая (когда запрос, к примеру, отправляется "кусочками" или ответ принимается "кусочками") - да. И как в этом случае отреагирует монитор - я не знаю, может быть тоже "никак"!
Мне, например, не понятно, почему монитор не отлавливает ситуацию, описанную в эксплойте - он должен это делать! Т.е. реально мы имеем дело с небольшим багом монитора, который просто не был до этого отловлен. И, безусловно, он совсем не стоит той шумихи, что вокруг него подняли!
Последний раз редактировалось aintrust; 28.05.2006 в 13:56.
Не видел я этого признания, может быть пропустил. Видел только то, что DVi назвал сообщение об уязвимости "глупостью" несколькими постами выше, с чем я совершенно не могу согласиться. Баг имеет место - это надо было просто признать и поскорее исправить, а не заниматься препирательствами с john-ом, кто лучше/хуже знает RFC.
Насчет "масштаба ошибки" - согласен, и классификация ее опасности как 4/10 мне кажется даже завышенной. Учитывая тот факт, что KAV/KIS - это комплексный продукт, где компоненты помогают и дополняют друг друга, можно сказать, что реальной опасности для пользователя в данном случае нет никакой.
На официальном сайте пресс-релиз
Всего один дурной бит - и гигабайты лежат в маразме.
Скажи мне свою OS и я скажу тебе КТО ты.
"И это - правильно!"
aintrust,Ес-но, какой еще протокол на уровне приложений и т.д.? Это вообще не то совсемСсылки на то, что по 80 порту можно пустить собственный протокол или "заксорить" содержимое также неуместныА вот тут Вы меня удивляете. Я знаю и читал Ваши посты на многих Форумах т.к. Человек Вы известный, но эта цитата неприминима, согласно, опять же, упомянутыми Вами RFC, угадайте как передаются данные IP? Я согласен с Вами, просто неточности есть в Ваших словах.т.к. именно он устанавливает величину тайм-аута при передаче запроса на http сервер, что и приводит к побайтной передаче!
Sanja,нет, конечно-же. При чем тут такая цитата? Насколько я понимаю, был запрос и неважно куда - на http или ftp и т.д. - только пришел первый же ответ (исключение UDP) - после сбора пакетов он (целый) тут же должен сканиться.А на ответ вобще сканнеру чихать Ж) он по запросу протокол определяет
Неофициальный форум Outpost Firewall http://forum.five.mhost.ru
"Слово произнесенное есть ложь!" Знаем-знаем...
А что конкретно вы имеете ввиду? Какую именно неточность вы увидели в моей фразе? И зачем мне нужно "гадать, как передаются данные IP" - мне уже лет 20 примерно кажется, что я это знаю...
>нет, конечно-же. При чем тут такая цитата?
Если вы невкурсе как работает протоколлер кава то это ваши личные трудности Ж) Перед тем как возмущатся надо бы наверное ознакомится с предметом Ж)
Всего один дурной бит - и гигабайты лежат в маразме.
Скажи мне свою OS и я скажу тебе КТО ты.
Ого, какая дискуссия развернулась - я думал, что только на форуме ЛК, да на anti-malware эту тему обсасывают
Теперь по существу.
Как сказал Саня, ошибку мы признали, и это ни для кого не является секретом. Хотя ошибка эта из ряда "а чего это вы использовали оператор = вместо += ?", т.е. без практического смысла вообще. Т.е. что до ее исправления, что после оного - ничего в безопасности пользователя не изменится, кроме морального удовлетворения "неизвестного исследователя" Евгения Гладких.
Далее, aintrust, Вы утверждаете, что опасна побайтная передача _с_сервера_ , а описанная "уязвимость" утверждает, что опасна побайтная передача _с_клиента_ . Чувствуете разницу? В первом случае возможно размещение иксплоита на сервере (а это действительно опасно, особенно если такие данные без проблем вытягиваются браузером), во втором - необходим его запуск на локальном компьютере (а вот с этим запуском, как я сказал, борются совсем другие компоненты защиты: файрволл, проактивка и файловый антивирус).
На anti-malware.ru Бубермот проводил подробные исследования.
Да, и еще: мне стала понятна причина публикации этой "уязвимости". Дело в том, что текущая бета DrWeb SpiderGate тоже не обрабатывает побайтный запрос к серверу. Стало быть, Евгений Гладких просто проверяет собственные баги на продукте ЛК.
Я еще не понял, что у него творится с логикой - ведь любые его пассажи на тему необходимости проверки HTTP (а именно: разговор про пресловутые wmf-иксплоиты, борьба с которыми в кеше браузера бесполезна, т.к. картинки сначала исполняются в процессе браузера. а лишь потом дампируются в кеш) разбиваются об отсутствие таковой защиты в продуктовой линейке DrWeb. Я бы понял еще, если б этот разговор пошел после релиза SpiderGate, а так - это какой-то детсад.
Действительно, слово "уязвимость" в данном контексте есть глупость. Ибо "уязвимость" и "баг", мягко говоря, не синонимы.Видел только то, что DVi назвал сообщение об уязвимости "глупостью" несколькими постами выше, с чем я совершенно не могу согласиться. Баг имеет место - это надо было просто признать и поскорее исправить, а не заниматься препирательствами с john-ом, кто лучше/хуже знает RFC.
Надеюсь, Вы обратили внимание, я не занимаюсь "препирательством, кто лучше/хуже знает RFC" (другое название: не меряюсь _сами_знаете_чем_). Размер своей компетенции я знаю, и он меня (и моего работодателя) вполне удовлетворяет.
Спасибо за дискуссию. Добро пожаловать на http://forum.kaspersky.com
Вы ничего не путаете?
"Эксплойт" передает http-запрос побайтно, но ответ сервера при этом принимается целиком. Что мешает (мешало) вашему трафикМонитору проанализировать этот ответ (в котором, собственно, и находится код вируса)? Насколько я понимаю - только то, что изначально вы парсите запрос к серверу, который был подан вам "в разобранном виде", но вы его просто не собрали (или неправильно собрали, или вообще не собирали - не знаю) перед анализом и принятием решения о том, какого рода трафик идет на сервер, поэтому и последующий ответ сервера проигнорировали. Я написал именно это - и ничего более. Это баг? Конечно же да - да вы и сами это подверждаете.
Насчет остального - я полагаю, что нет смысла продолжать дискуссию, все уже вроде и так всем ясно.
Извините, я спутал Ваше сообщение с сообщением Алексея Подтопалова. Вы действительно компетентны в данном вопросе. Ошибка, допущенная в парсере, заключалась именно в отсутствии детекта протокола - отсюда и отсутствие разбора протокола.
ОК, спасибо за разъяснение!
Ваши права в разделе
Ответить с цитированием
