Kaspersky antivirus 6: HTTP monitor bypassing

[J 0]

дайте линк, может что-то проясниться.

Прояснится только то, что в моём длинном посте про Dr.Web больше правды, чем кажется на первый взгляд =) Держите линк: http://inesp.ru/download/Interview.rar

Модератор выдели топик, а то хочется обсудить интервью, а в этом топике как-то стремно

[TiX 0]

передается по протоколу тельнета

тут неточность.. протокол телнета работает по 23 порту..

Вы имели ввиду,

по 1 байту

а чем конкретно..не имеет значения.

Тут тоже неточьность Ж) Ибо протокол не всегда привязан к порту Ж) Я могу поднять хттп сервер на порту 65534 и протокол обмена всеравно останется ХТТП Ж)

[broker 30]

telnet это всё таки сервис

[TiX 0]

Протокол тоже

http://www.networksorcery.com/enp/rfc/rfc137.txt

http://www.networksorcery.com/enp/protocol/telnet.htm#RFCs

[broker 30]

TiX

сервис работающий по протоколу.

ОК. :thanks: :off:

[Dmitry Perets 30]

Лень читать все.. поэтому отвечу.

1. Это не уязвимость а баг

2. Баг скоро будет исправлен.

Суть бага заключается в том что если запрос на сервер передается по протоколу тельнета - по 1 байту а не куском то парсер каспа обламывается.

Ну да. Короче, суть в том, что на безопасности это никоим образом не сказывается. По сути, скрипт john'a - это своего рода trojan-downloader. А ловить trojan-downloaders в задачи веб-антивируса не входит - для этого есть другие компоненты. Даже если парсер не обламается при побайтовой передаче, всё равно можно обламать его, передавая троян в зашифрованном виде и т.п. - т.е. веб-антивирус спасти от trojan-downloaders не может. А тот, кто может, делает это успешно.

[nobody.nogroup 0]

Ну да. Короче, суть в том, что на безопасности это никоим образом не сказывается. По сути, скрипт john'a - это своего рода trojan-downloader. А ловить trojan-downloaders в задачи веб-антивируса не входит - для этого есть другие компоненты. Даже если парсер не обламается при побайтовой передаче, всё равно можно обламать его, передавая троян в зашифрованном виде и т.п. - т.е. веб-антивирус спасти от trojan-downloaders не может. А тот, кто может, делает это успешно.

Т.е. вы хотите сказать, если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру javascript таким же образом, как это делает эксплоит и ваш браузер благополучно подохнет (ну, или, скажем, выполнит произвольный код) на этом javascript'е, защита от таких ситуаций - не есть работа HTTP-монитора?

Нафиг он тогда *вообще* нужен?

И сразу же попытаюсь защититься от смешных коментариев. Я там пишу, что простой вывод на экран содержимого скачанного вируса (без попытки сохранить вирус на диске или запустить его) не представляет абсолютно никакой опасности. Надеюсь, john не опустится до такого, но на случай если ВДРУГ СЛУЧАЙНО он захочет возразить, что команда

Код:

syswrite STDOUT, 'document is <'.$doc.'> len='.length($doc)."n";

ужасно опасна (в переменной $doc хранится вирус, любой, по вашему вкусу), и поэтому "11-классникам из ЛК" нужно было на это ругаться, я заранее привожу тут скриншот, показывающий, что SpIDer Guard (Dr.Web 4.33) так же считает её абсолютно безопасной.

Проверка HTTP-трафика - не задача SpIDer Guard'а.

Да и к тому же...

Ни один резидентный антивирус не способен контролировать запись в оперативную память. А если и будет способен, то производительность упадёт на порядки.

[broker 30]

вы хотите сказать, если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру javascript таким же образом, как это делает эксплоит и ваш браузер благополучно подохнет (ну, или, скажем, выполнит произвольный код) на этом javascript'е, защита от таких ситуация - не есть работа HTTP-монитора...

никто этого не говорил, в вашем случае можно будет говорить о проблеме в web-антивирусе.. но проблема будет заключатся в том, что кто придумает что-то новое.. а новое - это новое.

[headache 0]

1. Это не уязвимость а баг

Причем 100% серьезнейший баг в конкретной компоненте (то что за неё отработают другие компоненты это совсем другой разговор), и тут (с технической стороны) я с john-ом абсолютно согласен.

Суть бага заключается в том что если запрос на сервер передается по протоколу тельнета - по 1 байту а не куском то парсер каспа обламывается.

Но это нарушение RFC, при таком способе если на пути будет прокси например squid то запрос не пройдет. ответ "Bad Request";

А вот здесь будьте так добры привести RFC и пункт где это написано, ибо, на мой взгляд, это не так (по крайней мере ещё раз бегло просмотрев 2616 ничего подобного не увидел), например п.1.4:

HTTP communication usually takes place over TCP/IP connections. The

default port is TCP 80 [19], but other ports can be used. This does

not preclude HTTP from being implemented on top of any other protocol

on the Internet, or on other networks. HTTP only presumes a reliable

transport; any protocol that provides such guarantees can be used;

the mapping of the HTTP/1.1 request and response structures onto the

transport data units of the protocol in question is outside the scope

of this specification.

п.4.1:

In the interest of robustness, servers SHOULD ignore any empty

line(s) received where a Request-Line is expected. In other words, if

the server is reading the protocol stream at the beginning of a

message and receives a CRLF first, it should ignore the CRLF.

Четко написано "stream", значит ни о каких ограничениях на минимальный пакет нет.

А насчет Squid - и давно он стал примером соблюдения стандартов?

[Dmitry Perets 30]

Т.е. вы хотите сказать' date=' если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру javascript таким же образом, как это делает эксплоит и ваш браузер благополучно подохнет (ну, или, скажем, выполнит произвольный код) на этом javascript'е, защита от таких ситуаций - не есть работа HTTP-монитора?

Нафиг он тогда *вообще* нужен?

[/quote']

Так давайте может вы сначала напишете именно такой скрипт, а уже потом ваши коллеги будут кричать про мега-уязвимость и оскорблять конкурентов (что, кстати, не к месту, независимо от наличия уязвимости)? Вы же держите веб-сервер. Выложите там скрипт, который будет передавать моему браузеру Eicar именно таким образом. Киньте сюда линк, я проверю, и далее мы обсудим результаты.

Мне ЛК денег не платит, фотографиями Е.К. моя стенка не обклеена => стало быть, я без проблем признаю, что в продукте ЛК есть уязвимость. Только покажите мне её. А то, что было показано скриптом john'а - это, как я уже писал, такой же обход веб-антивируса, как перенос вируса на дискетке вместо e-mail - обход почтового антивируса.

Да и к тому же...

Ни один резидентный антивирус не способен контролировать запись в оперативную память. А если и будет способен' date=' то производительность упадёт на порядки.[/quote']

Я с вами полностью согласен. Я не считаю, что он должен это контролировать. Тем постом я просто перестраховался на случай если john пойдёт на "принцип спорщика" и расскажет, что КАВ подверг систему опасности, ибо eicar на экране монитора страшен. Теоретически конечно страшен немножко, но... впрочем, вы уже сами всё сказали.

[TiX 0]

Т.е. вы хотите сказать, если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру javascript таким же образом, как это делает эксплоит и ваш браузер благополучно подохнет (ну, или, скажем, выполнит произвольный код) на этом javascript'е, защита от таких ситуаций - не есть работа HTTP-монитора?

Нафиг он тогда *вообще* нужен?

Скрипт неможет выдать ничего как эксплойт просто потому что вы наверное незнаете перл и невидите что вся суть в запросе. Эксплойт ничего не отдает, а только запрашивает.

Протокол ХТТП определяется на уровне запроса.. !А НЕ ОТВЕТА! если запрос корректен то пофигу что выдасл javascript. Если вы этого непонимаете то что вы делаете в антивирусной компании? Ж)

А вот какраз когда человек зайдет через брайзер и явя скипт выдаст ему что-то нехорошее то это нехорошее будет пойманно без проблем.

Добавлено спустя 6 минут 53 секунды:

1. Это не уязвимость а баг

Причем 100% серьезнейший баг в конкретной компоненте (то что за неё отработают другие компоненты это совсем другой разговор), и тут (с технической стороны) я с john-ом абсолютно согласен.

Суть бага заключается в том что если запрос на сервер передается по протоколу тельнета - по 1 байту а не куском то парсер каспа обламывается.

Но это нарушение RFC, при таком способе если на пути будет прокси например squid то запрос не пройдет. ответ "Bad Request";

А вот здесь будьте так добры привести RFC и пункт где это написано, ибо, на мой взгляд, это не так (по крайней мере ещё раз бегло просмотрев 2616 ничего подобного не увидел), например п.1.4:

HTTP communication usually takes place over TCP/IP connections. The

default port is TCP 80 [19], but other ports can be used. This does

not preclude HTTP from being implemented on top of any other protocol

on the Internet, or on other networks. HTTP only presumes a reliable

transport; any protocol that provides such guarantees can be used;

the mapping of the HTTP/1.1 request and response structures onto the

transport data units of the protocol in question is outside the scope

of this specification.

п.4.1:

In the interest of robustness, servers SHOULD ignore any empty

line(s) received where a Request-Line is expected. In other words, if

the server is reading the protocol stream at the beginning of a

message and receives a CRLF first, it should ignore the CRLF.

Четко написано "stream", значит ни о каких ограничениях на минимальный пакет нет.

А насчет Squid - и давно он стал примером соблюдения стандартов?

Написано "where a Request-Line is expected"

Строка - 1 буфер оканчивающийся комбинациет CRLF.

Ограничения на размер запроса нету.. посылай хоть 100 Строк.

[headache 0]

Написано "where a Request-Line is expected"

Строка - 1 буфер оканчивающийся комбинациет CRLF.

1) Request-Line задает формат (п.5.1), а не то, как этот Request-Line добирался до сервера. Т.е. в данном случае Request-Line это вообще имя единицы запроса.

2) У вас проблемы с английским ? "...if the server is reading the protocol stream..." = "...если сервер читает протокольный поток..." - дальше можно не читать. stream это однозначно посимволный доступ.

Не понятно с чем спорите. В HTTP нету (да и быть не может просто by design стека протоколов) ограничений как там эта строка запроса добралась до сервера, хоть побайтно, хоть целиком весь запрос одним пакетом - лишь бы с сохранением порядка и без потерь.

Поэтому это 100% баг в модуле, разбирающем поток. Всё остальное на самом деле отмазки разработчика. Да со всеми стандартными HTTP-клиентами будет работать и без побайтного разбора, но это всё равно баг - HTTP протокол разбирается НЕ ВСЕГДА.

Ограничения на размер запроса нету.. посылай хоть 100 Строк.

Вы разницу между HTTP-запросом и размером данных в tcp-пакете понимаете? Ваше замечание в обсуждаемом контексте бессмысленно.

[TiX 0]

>stream это однозначно посимволный доступ.

Да кто вам сказал такое Ж) Поток - это непрерывный обмен информациетй в любом виде - по 1, 10, 20, 30, 40 или 50 символов или по 1 мб за раз..

>Поэтому это 100% баг в модуле, разбирающем поток

Дык ктож спорит то? Вопрос как его представили общественности.

[nobody@nowhere 0]

Результаты обещанной проверки смотрите здесь: http://forum.kaspersky.com/index.php?showt...st&p=120860

И сразу же попытаюсь защититься от смешных коментариев. Я там пишу, что простой вывод на экран содержимого скачанного вируса (без попытки сохранить вирус на диске или запустить его) не представляет абсолютно никакой опасности. Надеюсь, john не опустится до такого, но на случай если ВДРУГ СЛУЧАЙНО он захочет возразить, что команда

syswrite STDOUT, 'document is <'.$doc.'> len='.length($doc)."n";

ужасно опасна (в переменной $doc хранится вирус, любой, по вашему вкусу), и поэтому "11-классникам из ЛК" нужно было на это ругаться, я

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

несколько отвлекся - давайте посмотрим, что должен делать http monitor? он должен защищать браузер от вредоносного контента эксплуатирующего уязвимости браузера (и в случае Windows - ее самое). не его дело вобщем-то проверять скачевыемые файлы помещаемые на диск, тут on access монитор превосходно справится. не вызывает сомнения что любой FW защитит от даунлоадера пошедшего что-то качать из сети.

с этим Вы согласны? если нет, то, действительно, говорить дальне не о чем.

заранее привожу тут скриншот, показывающий, что SpIDer Guard (Dr.Web 4.33) так же считает её абсолютно безопасной.

Остальные подробности читайте по линку. Имхо на этом тема себя исчерпала.

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

[Бубермот 0]

Вобщем, решил я проверить другой сценарий, когда неправильный сервер разбивает ответ. Как раз в этом месте могла бы быть уязвимость, т.к. если стандартный браузер на некоем сервере получает нечто в обход вебфильтра, значит вебфильтру место на помойке. Достал старую лабу по сетям, переделал в примитивный вебсервер, который сидит на 8080 порту и на любой запрос кидает минимальный заголовок (статус + content-type) и тело еикара по байту. На первом же телнетном запросе вебфильтр касперского пропустил еикар. Решил попробовать через браузер, открываю страницу в опере (9.0 beta) - вместо тела еикара чистая страница. Пробовал IE (6.0), мозилку файрфокс(1.07), lynx, download master - никто не захотел воспринимать ответ от моего сервера. Понятно, что-то не то с заголовком ответа. Передал его одним махом - касперский завизжал. Короче, после серии опытов выяснил, что и касперский и браузеры отказываются воспринимать ответ, если в первой строке "HTTP/<версия>" передаётся не одним блоком. Возможно, где-то существует браузер, способный обработать разбитое начало заголовка, тогда баг в разборе http ответа действительно будет иметь практическое значение, иначе вреда от него никакого.

PS: Зато при побайтовой передаче, после того как касперский поймает вируса в окне браузера показывают не стандартную "я только что тебе жизнь спас" страницу каспера, а начало тела вирусни. Т.е. хоть возможность себя похвалить у каспера обламывается.

PPS: исходник в аттаче. Критичная к разбиению часть заголовка передаётся в 84/85 строках.

infiltrator.c

infiltrator.c

[nobody@nowhere 0]

Вобщем, решил я проверить другой сценарий, когда неправильный сервер разбивает ответ.

а если выдавать в ответ разбитый файл не как chunked или octet-stream побайтно, а multipart/byteranges?

[Dmitry Perets 30]

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

[/quote']

Мне казалось, что уже всем ясно, что никакой проблемы с безопасностью у пользователей КАВКИС от вашего скрипта нету. Доработать хттп-парсер так, чтобы ловил и ваш скрипт, можно. Вполне возможно, что ЛК так и сделает - почему нет. Только тогда вы придёте и напишите другой trojan-downloader (на этот раз точно не по RFC), потом третий, а потом вам надоест страдать ерундой, и вы один раз просто напишите скрипт, качающий eicar по стандартному протоколу, но в зашифрованном виде. Что прикажете, научить http-парсер искать ключ в теле скрипта для расшифровки? Или наконец признаете, что ЛОВИТЬ TROJAN-DOWNLOADERS - ЭТО НЕ ЗАБОТА ВЕБ-АНТИВИРУСА, А ЗАБОТА ДРУГИХ КОМПОНЕНТОВ ЗАЩИТЫ? А, секундочку... Вы как раз это признаёте ниже...

несколько отвлекся - давайте посмотрим' date=' что должен делать http monitor? он должен защищать браузер от вредоносного контента эксплуатирующего уязвимости браузера (и в случае Windows - ее самое). не его дело вобщем-то проверять скачевыемые файлы помещаемые на диск, тут on access монитор превосходно справится. не вызывает сомнения что любой FW защитит от даунлоадера пошедшего что-то качать из сети.

с этим Вы согласны? если нет, то, действительно, говорить дальне не о чем.

[/quote']

Ну да, именно так! Именно это я и пытаюсь вам сказать =)

переливаливание с больной головы на здоровую. пусть самая первая бета SG считает все что ей угодно' date=' спроса с нее - никакого.[/quote']

Да я не про SpiderGate вообще, а про SpiderGuard! Это к тесту http-парсеров не относится - я же чётко сказал в своём посте, зачем я привёл этот пример.

Секунду... Я правильно понял намёк? Что, SpiderGuard пока что тоже не ловит ваш мега-скрипт? =)))))))) Бугога! Ну вы же понимаете, что после выхода релиза все ваши скрипты будут на нём проверены первым делом, даже раньше, чем утренняя чистка зубов? =) Кстати, когда релиз-то?

P.S. Да, кстати, я всё ещё жду, когда Ilya напишет настоящий эксплоит на основе вашего скрипта и кинет мне линк.

Добавлено спустя 13 минут 48 секунд:

Короче' date=' после серии опытов выяснил, что и касперский и браузеры отказываются воспринимать ответ, если в первой строке "HTTP/<версия>" передаётся не одним блоком. [/quote']

Ч.Т.Д. =) Именно об этом твердят разработчики ЛК уже третий день. Веб-антивирус тестировали в реальных условиях, а не в гипотетических. Ибо он должен защищать реального юзера, лазающего в инете через реальный браузер. Вот его цель. А те, кто гонится за "теоретическим превосходством", зачастую получают нечто, с чем в реальных условиях работать невозможно (в результате компонент отключают, и теоретическое превосходство остаётся в теории).

P.S. А если где-то когда-то случайно появится такой браузер, о котором вы говорите, то нет никакой проблемы обновить веб-антивирус. Модули-то обновляемые, а обновления частые.

[Бубермот 0]

john

всё ещё хуже - я не то, что мульмипарт, даже чанкед/гзиппед не тестировал. Исходнике у вас просто запрос побайтно отправляется, соответственно я в меру своих сил протестировал такой же простой, но потенциально более опасный момент. С моментом каспер более-менее справился.

Я, кстати, вас понимаю. Наверняка читали описание протокола и про себя матерились, представляя, как придётся этот этот мультипарт ответ проверять, толи выделять память, заполнять её и проверять результат, толи как-то учитывать возможность, что начало/конец вируса может быть в данный момент недоступно. И вот решили посмотреть как у конкурента, а он на самом простом примере облажался.

[headache 0]

>stream это однозначно посимволный доступ.

Да кто вам сказал такое Ж) Поток - это непрерывный обмен информациетй

Садитесь. 2 бала. Домашнее задание: разница между потоковыми и датаграмными транспортами (только не udp, а с гарантированной доставкой и соблюдением последовательности).

Подсказка: известна ли серверу точная длина 1-й строки HTTP-запроса ДО получения (чтения из сокета) первой последовательности CR LF? Правильно - её (последовательность CR LF) придется искать перебирая полученный от tcp-сокета буфер посимвольно, начиная с первого. Вот вам и посимвольный доступ.

А ваша манера вести спор начинает немного раздражать. Вначале вы пишете:

Суть бага заключается в том что если запрос на сервер передается по протоколу тельнета - по 1 байту а не куском то парсер каспа обламывается.

Но это нарушение RFC, ...

Когда вам указывают на вашу ошибку (т.к. на самом деле никакого нарушения RFC нет), вы вместо того чтобы либо признать ошибку, либо привести цитату из RFC, согласно которой нарушение есть, начинаете спорить и цепляться к мелочам (словам). А потом пишете:

обмен информациетй в любом виде - по 1, 10, 20, 30, 40 или 50 символов или по 1 мб за раз..

Разницу между своими 2-мя отквоченными фразами видите?

>Поэтому это 100% баг в модуле, разбирающем поток

Дык ктож спорит то?

Да вот вы и спорите, пишите про какие-то "нарушения RFC", потом пытаетесь "запутать следствие".

Вопрос как его представили общественности.

Я бы сказал самое важное в данном эпизоде, это "КТО его представил общественности".

[Бубермот 0]

Проверил вариант с чанкед передачей - каспер ловит без проблем. Попробовал реализовать мультипарт/байтрангес - никто не захотел ответ воспринимать. Толи я чего-то не того сформировал, даже проверить не на чем. IE запускает даунлоадер, опера предлагает сохранить на диск файл с непонятным Content-type: multipart/byteranges. Download Master сохраняет файл в том виде, в котором получил, т.е.

--сепаратор

контент-тайп

контент-рейндж

контент

--сепаратор...

Мозилка ближе всех: она отображает содержимое части, полученой последней.

Вообще с мультипартом проблема надуманна: RFC требует от клиента понимания такого ответа только в одном случае - если тот сам попросил в одном запросе 2 или более неперекрывающихся куска файла. Неудивительно, что клиенты забивают на эту часть. Тем более браузеры, которые и докачку (т.е. 1 range запрос) не поддерживают.

multipartAndChunked.rar

multipartAndChunked.rar

[Сергей Ильин 1538]

ЛК опубликовали специальный пресс-релиз на тему уязвимости, причем там есть ссылка на эту ветку форума

http://www.kaspersky.ru/technews?id=187430186

Официальное заявление «Лаборатории Касперского»

Мы согласны с тем, что сформированный подобным образом запрос не будет обработан веб-антивирусом Kaspersky Internet Security 6.0.

Однако мы утверждаем, что распространенные браузеры (MS Internet Explorer, Mozilla Firefox, Opera) и программы-даунлоадеры никогда не посылают запрос к серверу в таком виде.

Подобный код может быть исполнен только извне браузера, силами отдельно запущенной программы. Программы, осуществляющие подобные действия (скачивание на компьютер вредоносных программ в обход систем защиты компьютера), выделены в отдельный класс вредоносных программ — Trojan-Downloader.

Более того, программы этого класса не стеснены рамками протокола HTTP и могут использовать любое шифрование и любой протокол для скачивания malware.

Модуль веб-антивируса KIS 6.0 не предназначен для борьбы с запущенным на компьютере процессом Trojan-Downloader. Для борьбы с подобными видами вредоносных программ в продукте Kaspersky Internet Security 6.0 предусмотрены следующие модули:

* Антихакер

* Проактивная защита

* Файловый антивирус

Таким образом, программный комплекс KIS 6.0 обеспечивает полную защиту компьютера пользователя, и опубликованная «уязвимость» никак не влияет на безопасность компьютера.

Второй представленный на форуме сайта Security Focus скрипт, демонстрирующий уязвимость в парсере протокола POP3, имитирует не почтовую программу (ни один почтовый клиент так не работает), а снова Trojan-Downloader. То есть, демонстрируется не уязвимость в защите почтового трафика при помощи KIS 6.0, а вредоносная программа, которая позволяет скачивать вирусы по протоколу POP3 в обход модуля защиты протокола POP3 KIS 6.0.

Другими словами, чтобы воспользоваться этой уязвимостью для скачивания вредоносной программы в обход защиты KIS 6.0 необходимо запустить особую вредоносную программу, которая не является почтовым клиентом — то есть, обычному пользователю, работающему с почтой из какого-либо обычного распространенного почтового клиента по протоколу POP3 эта уязвимость никак не угрожает.

Для предотвращения возможности заражения посредством использующих данную уязвимость специально написанных программ в середине следующей недели «Лаборатория Касперского» выпустит соответствующие hotfix'ы для продуктов Kaspersky Anti-Virus 6.0 и Internet Security 6.0.

«Лаборатория Касперского» сожалеет о том, что потенциально опасная информация была сразу опубликована в открытом доступе вместо того, чтобы, как принято поступать в антивирусном сообществе, сообщить об обнаруженной проблеме разработчикам программного комплекса.

Вот такое вот заявление сделала ЛК, что думаете об этом?

[Dmitry Perets 30]

Вот такое вот заявление сделала ЛК, что думаете об этом?

Имхо грамотно. Меня порадовало. До публичного упоминания тех, кто не поступил так, "как принято поступать в антивирусном сообществе", ЛК не опустилась.

[nobody@nowhere 0]

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

Мне казалось, что уже всем ясно, что никакой проблемы с безопасностью у пользователей КАВКИС от вашего скрипта нету. Доработать хттп-парсер так, чтобы ловил и ваш скрипт, можно. Вполне возможно, что ЛК так и сделает - почему нет. Только тогда вы придёте и напишите другой trojan-downloader (на этот раз точно не по RFC), потом третий, а потом вам надоест страдать ерундой, и вы один раз просто напишите скрипт, качающий eicar по стандартному протоколу, но в зашифрованном виде. Что прикажете, научить http-парсер искать ключ в теле скрипта для расшифровки? Или наконец признаете, что ЛОВИТЬ TROJAN-DOWNLOADERS - ЭТО НЕ ЗАБОТА ВЕБ-АНТИВИРУСА, А ЗАБОТА ДРУГИХ КОМПОНЕНТОВ ЗАЩИТЫ? А, секундочку... Вы как раз это признаёте ниже...

несколько отвлекся - давайте посмотрим, что должен делать http monitor? он должен защищать браузер от вредоносного контента эксплуатирующего уязвимости браузера (и в случае Windows - ее самое). не его дело вобщем-то проверять скачевыемые файлы помещаемые на диск, тут on access монитор превосходно справится. не вызывает сомнения что любой FW защитит от даунлоадера пошедшего что-то качать из сети.

с этим Вы согласны? если нет, то, действительно, говорить дальне не о чем.

Ну да, именно так! Именно это я и пытаюсь вам сказать =)

отлично. тогда идем дальше. почему именно HTTP а не идиотское предложение писать свой протокол. неужели еще не понятно? потому что дыряв Веб-антивирус... методика показанная в скрипте осужествима пряма из Вашего любимого браузера - vbscript, java applet, flash - любой из них может проделать все тоже самое. в итоге - веб-монитор мы обошли, FW обходить нет нужды, он мило и любезно пропустит браузер скачать все что угодно по http. думаю что он при этом скачает говорить не нужно, не так ли? любой эксплоит IE. любую ерунду роняющую венду. не так ли? то что в ЛК так этого и не поняли - очень печально. еще более печально что азбучные истины нужно расказывать специалистам по безопастности. а подсказок было море, но видимо не судьба - нужно разжевать и в рот положить.

Добавлено спустя 5 минут 9 секунд:

Вообще с мультипартом проблема надуманна: RFC требует от клиента понимания такого ответа только в одном случае - если тот сам попросил в одном запросе 2 или более неперекрывающихся куска файла. Неудивительно, что клиенты забивают на эту часть. Тем более браузеры, которые и докачку (т.е. 1 range запрос) не поддерживают.

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

Добавлено спустя 2 минуты 23 секунды:

Мы согласны с тем, что сформированный подобным образом запрос не будет обработан веб-антивирусом Kaspersky Internet Security 6.0.

Однако мы утверждаем, что распространенные браузеры (MS Internet Explorer, Mozilla Firefox, Opera) и программы-даунлоадеры никогда не посылают запрос к серверу в таком виде.

Подобный код может быть исполнен только извне браузера, силами отдельно запущенной программы.

...

Вот такое вот заявление сделала ЛК, что думаете об этом?

печально. сценарий атаки - чуть выше. не понимаю как можно не осозновать столь тривиальных вещей. тем более со столькими подсказками

[TiX 0]

>методика показанная в скрипте осужествима пряма из Вашего любимого браузера - vbscript, java applet, flash - любой из них может проделать все тоже самое. в итоге - веб-монитор мы обошли

Вы неправы.. как это не печально Ж) Экземпляр vb-scripta, java-appleta, flash который загрузится со странички в обход при заходе на сайт браузером можно?

То о чем вы пишите здесл - удаленнвя уязвомость, то что вы показали как PoC (perl script) - локальная уязвимость. Разницу видите? Ж)

[nobody@nowhere 0]

>методика показанная в скрипте осужествима пряма из Вашего любимого браузера - vbscript, java applet, flash - любой из них может проделать все тоже самое. в итоге - веб-монитор мы обошли

Вы неправы.. как это не печально Ж) Экземпляр vb-scripta, java-appleta, flash который загрузится со странички в обход при заходе на сайт браузером можно?

То о чем вы пишите здесл - удаленнвя уязвомость, то что вы показали как PoC (perl script) - локальная уязвимость. Разницу видите? Ж)

Саня, писание троянов - Ваша прерогатива. все исходные данные есть - дерзайте.

Добавлено спустя 6 минут 40 секунд:

Вот такое вот заявление сделала ЛК, что думаете об этом?

Имхо грамотно. Меня порадовало. До публичного упоминания тех, кто не поступил так, "как принято поступать в антивирусном сообществе", ЛК не опустилась.

в сообществе принято отсылать сообщение о уязвимости вендору и в секьюрити листы, не так ли? за деталями моего видения проблемы - в соседний тред на этом же форуме. проблема прочтения и адекватности восприятия вендора - это его личная проблема, не сообщества. они могут отмазываться тем что сообщения не получали, но листы - получали. а свою адекватность представители ЛК публично продемонстрировали, не в первый раз. отмазки... и все вместо того что бы исправить тривиальную ошибку и оградить пользователей от дыры диаметром с солнце