Kaspersky antivirus 6: HTTP monitor bypassing - Страница 3 - Выбор домашних средств защиты - Форумы Anti-Malware.ru Перейти к содержанию
nobody@nowhere

Kaspersky antivirus 6: HTTP monitor bypassing

Recommended Posts

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
TiX
передается по протоколу тельнета

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

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

по 1 байту

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
broker

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
broker

TiX

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

ОК. :thanks: :off:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dmitry Perets
Лень читать все.. поэтому отвечу.

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
nobody.nogroup
Ну да. Короче, суть в том, что на безопасности это никоим образом не сказывается. По сути, скрипт 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
вы хотите сказать, если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру javascript таким же образом, как это делает эксплоит и ваш браузер благополучно подохнет (ну, или, скажем, выполнит произвольный код) на этом javascript'е, защита от таких ситуация - не есть работа HTTP-монитора...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
headache
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

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

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

[/quote']

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
TiX
Т.е. вы хотите сказать, если чей-либо скрипт на чьём-либо сервере выдаст вашему браузеру 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
Написано "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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
nobody@nowhere
Результаты обещанной проверки смотрите здесь: 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 считает все что ей угодно, спроса с нее - никакого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Бубермот

Вобщем, решил я проверить другой сценарий, когда неправильный сервер разбивает ответ. Как раз в этом месте могла бы быть уязвимость, т.к. если стандартный браузер на некоем сервере получает нечто в обход вебфильтра, значит вебфильтру место на помойке. Достал старую лабу по сетям, переделал в примитивный вебсервер, который сидит на 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
Вобщем, решил я проверить другой сценарий, когда неправильный сервер разбивает ответ.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dmitry Perets

спасибо Дмитрий' 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. А если где-то когда-то случайно появится такой браузер, о котором вы говорите, то нет никакой проблемы обновить веб-антивирус. Модули-то обновляемые, а обновления частые.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Бубермот

john

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
headache
>stream это однозначно посимволный доступ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Бубермот

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

--сепаратор

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

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

контент

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

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

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

multipartAndChunked.rar

multipartAndChunked.rar

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин

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

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
Вот такое вот заявление сделала ЛК, что думаете об этом?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
nobody@nowhere

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

Мне казалось, что уже всем ясно, что никакой проблемы с безопасностью у пользователей КАВКИС от вашего скрипта нету. Доработать хттп-парсер так, чтобы ловил и ваш скрипт, можно. Вполне возможно, что ЛК так и сделает - почему нет. Только тогда вы придёте и напишите другой 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

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

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

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

Поделиться сообщением


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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • PR55.RP55
      * адрес страницы (ReferrerUrl) и адрес самого файла (HostUrl) в метке появились в Windows 10 версии 1703, их записывают браузеры, например Edge и Chrome. В статье показано, как посмотреть эти данные в Windows 11 https://www.comss.ru/page.php?id=22105
    • Ego Dekker
      ESET Cyber Security 10.0.2100  (macOS 13/14/15/26/27)
                                                                                  ●
              Руководство пользователя ESET Cyber Security 10  (PDF-файл)
                                                           
      Полезные ссылки:
      Технологии ESET
      Удаление антивирусов других компаний
      Как удалить ESET Cyber Security?
    • Ego Dekker
      Домашние антивирусы для Windows были обновлены до версии 19.2.10.
    • PR55.RP55
      1) Ситуация когда нет доступа к virustotal.com ( и другим ресурсам ) Что предлагаю: а) На примере Firefox 155 - Happy Eyeballs v3: подключение сразу несколькими путями *Браузер больше не выбирает маршрут до сайта заранее, а пробует несколько вариантов подключения параллельно и работает через тот, который отозвался первым. Выигрыш заметнее всего в сетях, где IPv4 или IPv6 работает медленно либо нестабильно: раньше браузер мог упереться в неотвечающий адрес и ждать таймаута, теперь соединение уходит по резервному пути без паузы. б) Если сайт полностью не доступен - то, при потоковой проверке файлов не заставлять пользователя "бесконечно" ждать... 2) Драйвер фаервола - при проверке. По хорошему программа сама должна знать какие файлы её, какие нет и всякий раз не лезть к ним и не пытаться получить доступ к собственному файлу ?  
    • AM_Bot
      «Инфосистемы Джет» активно развивает концепцию антихрупкости. Эта компания разработала инструменты для её практического применения — первый Фреймворк антихрупкой ИТ-архитектуры и Индекс антихрупкости для построения киберустойчивого бизнеса.      1. Введение2. Что такое антихрупкость ИТ-архитектуры3. Назначение инструментов, разработанных компанией «Инфосистемы Джет»3.1. Фреймворк антихрупкой ИТ-архитектуры3.2. Индекс антихрупкости4. Как проходит оценка4.1. Заполнение профиля компании4.2. Построение бенчмарка4.3. Прохождение опроса4.4. Оценка результатов5. ВыводыВведениеРезонансные атаки на крупнейшие российские компании, которые мы регулярно освещаем, вскрыли системную проблему: реальная операционная готовность к инцидентам остаётся на низком уровне, даже если система защиты формально выстроена. Как показало недавнее исследование компании «Инфосистемы Джет», пережить кибератаку не готовы 64 % из 50 российских компаний. Хуже всего ситуация обстоит в госсекторе и ритейле — при этом именно эти отрасли входят в число наиболее атакуемых.Защита, которая создавалась, чтобы остановить злоумышленника, теперь может лишь его замедлить — и одной способности «не пустить» стало недостаточно. Закупленные СЗИ создают иллюзию надёжности: организация выглядит защищённой, но в момент реальной атаки оказывается уязвимой.В условиях массовых взломов и эволюции атакующих стратегий на первое место выходит принцип управляемого ухудшения ситуации. Взлом с большой вероятностью произойдёт, но мы должны уметь работать под атакой, управлять кризисом и быстро восстановиться. Также необходимо выстроить зрелые процессы реагирования на угрозы, восстановления после инцидентов и обеспечения непрерывности бизнеса даже в условиях атаки. В ответ на этот вызов ИТ-компания «Инфосистемы Джет», работающая на российском рынке с 1991 года, предложила использовать концепцию антихрупкой ИТ-архитектуры.Её суть заключается в том, что ИТ-инфраструктура должна не просто выдерживать сбои, атаки и неблагоприятные обстоятельства, а по-настоящему быть к ним готовой, эффективно их преодолевать и даже извлекать из них пользу, становясь надёжнее и укрепляя свои позиции среди конкурентов.Что такое антихрупкость ИТ-архитектурыКонцепция антихрупкости впервые была предложена учёным Нассимом Талебом, статистиком, бывшим трейдером и риск-менеджером, который прославился изучением влияния случайных и непредсказуемых событий на мировую экономику и биржевую торговлю. В книге «Чёрный лебедь. Под знаком непредсказуемости» (The Black Swan), вышедшей в 2007 году, он ввёл сам термин «чёрный лебедь» для описания редких и маловероятных событий, имеющих огромные последствия, и пришёл к выводу, что вместо попыток их предсказания логичнее создавать системы, способные не просто пережить хаос, но и становиться после него сильнее. Именно это понимание легло в основу идеи антихрупкости, которая уже была детально раскрыта Талебом в книге 2012 года «Антихрупкость. Как извлечь выгоду из хаоса» (Antifragile: Things That Gain From Disorder).Вдохновившись концепцией антихрупкости, аналитики компании «Инфосистемы Джет» решили развивать эти идеи и продвигать их в России. Антихрупкая ИТ-архитектура — не гонка за новыми инструментами. Она строится вокруг способности пережить полный жизненный цикл атаки: подготовиться к ней, замедлить злоумышленника, обнаружить вторжение, сократить ущерб, восстановить бизнес и перестроиться после инцидента. Для практической реализации концепции антихрупкости «Инфосистемы Джет» разработали первый Фреймворк антихрупкой архитектуры и Индекс антихрупкости, позволяющие выявить слабые места и сформировать дорожную карту усиления защиты.Назначение инструментов, разработанных компанией «Инфосистемы Джет»Как же перейти от понимания концепции антихрупкости к её реализации? В этом помогут разработанные вендором инструменты, которые мы рассмотрим ниже.Фреймворк антихрупкой ИТ-архитектурыФреймворк антихрупкой ИТ-архитектуры представляет собой открытый и практичный инструмент, который объединил опыт инженеров, аудиторов, консультантов и экспертов-практиков по защите сети и построению ИТ-инфраструктуры. Он разработан командой «Инфосистемы Джет» во главе с руководителем отдела развития консалтинга по ИБ Александром Морковчиным.Сценарии использования фреймворка охватывают три ключевые рыночные потребности. Первая — оценка текущего уровня киберустойчивости с помощью единой измеримой «линейки» для сопоставления с конкурентами и отраслевыми лидерами. Вторая — планирование развития на основе каталога проверенных практик и выбор вектора роста. Третья — трансформация: пошаговый переход от фактического состояния к целевому уровню киберустойчивости. Фреймворк имеет иерархическую логику: он строится по каскадной модели «в крупную клетку», т. е. на высоком уровне абстракции, без погружения в мелкие детали. Всего существует пять уровней детализации, где каждый следующий уровень конкретизирует предыдущий. Это позволяет последовательно двигаться от общего видения (стратегии) по уровням детализации к конкретным действиям (практике), сохраняя гибкость и системность.Фреймворк доступен на официальном сайте и не требует установки дополнительных расширений. Рисунок 1. Каскадная модель фреймворка антихрупкой ИТ-архитектуры Разберём каскад по уровням:Уровень 0. ДистанцииДистанции описывают фазы жизненного цикла относительно кибервторжения.Уровень 1. Цели («Чего хотим достичь»)Здесь выделяется семь стратегий. Это верхнеуровневые направления для достижения антихрупкости: например, «подготовка и прогнозирование», «адаптация и перестройка». Их цель — сформировать киберустойчивый каркас, дополнив классическую ИБ тем, чего часто не хватает в реальной атаке: связью с ИТ-архитектурой, непрерывностью, восстановлением, кризисным управлением и постоянным улучшением. Таблица 1. Семь стратегий антихрупкостиСтратегияВопрос, на который она отвечаетСистемное развитие и контрольРазвивается ли ИБ оправданно с точки зрения бизнеса?Подготовка и прогнозированиеПонимаем ли мы, как нас будут атаковать и какое звено сломается первым?Вовлечение и нападениеЗнаем ли мы, кто и как готовится нас атаковать — и можем ли перехватить инициативу?Защита, замедление, сдерживаниеЧто не даст атакующему быстро развить успех после проникновения?Обнаружение и реагированиеПоймём ли мы, что враг уже внутри, до того как он ударит?ВосстановлениеЕсть ли у бизнеса «План Б» на случай потери инфраструктуры?Адаптация и перестройкаСтанет ли компания сильнее после инцидента? Уровень 2. Правила реализации («Как себя ведём»)Здесь выделяется 10 принципов. Принципы связывают стратегии с действиями: это установки, задающие поведение. Например, принцип «нулевого доверия» или «безопасности по умолчанию». Уровень 3. Области применения («Где развиваем способности») Здесь выделяются 33 домена — тематические области, группирующие практики по функциональной принадлежности. Каждый домен описывает определённую способность организации. Уровень 4. Конкретные действия («Что делаем»)Здесь выделяется 390+ практик. Практики — конкретные меры и действия, которые организация должна реализовать для достижения целей киберустойчивости. Рисунок 2. Распределение стратегий антихрупкости по четырём дистанциям Вышеописанная схема является интерактивной: кликнув на домен, можно ознакомиться с относящимися к нему практиками. Рисунок 3. Информация о входящих в домен «Обнаружение и реагирование» практиках Также можно использовать строку поиска для выделения интересующих вас практик. Рисунок 4. Результат поискового запроса Фреймворк можно выгрузить в виде файла формата XLS, в котором также представлен инструмент самооценки. Рисунок 5. Фрагмент фреймворка в формате XLS Индекс антихрупкостиИндекс антихрупкости — показатель, позволяющий оценить в процентном соотношении, насколько компания готова к «чёрным лебедям», т. е. труднопредсказуемым событиям. Индекс построен на базе фреймворка и отвечает на вопрос: способна ли компания пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. Итог оценки — индекс антихрупкости от 0 до 100 %, разбор по направлениям защиты и сравнение с другими участниками индустрии. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов.Индекс не заменяет регуляторные оценки, а дополняет их в областях, которые проверяют реальную киберустойчивость: восстановление и непрерывность бизнеса, кризис-менеджмент, threat hunting, безопасная разработка, безопасность ИИ, отказоустойчивость, культура киберучений и другие. Разберём, как пользоваться инструментом оценки.Как проходит оценкаС сервисом можно ознакомиться на официальном сайте. Вы отвечаете на сто коротких вопросов о том, какие практики киберустойчивости есть в компании. Оценка полностью анонимна: контактные данные и название компании не запрашиваются. У каждой оценки есть только уникальный идентификатор — он понадобится, если вы захотите задать вопрос по полученным результатам. Рисунок 6. Расчёт Индекса антихрупкости (приветственное окно) Заполнение профиля компанииДля получения оценок, релевантных профилю вашей организации, необходимо указать параметры из выпадающего списка: Сфера деятельности компании.Общее количество сотрудников.Число ИБ-сотрудников.Число ИТ-сотрудников.Оценку формирует руководитель ИБ или тот, кто отвечает за информационную безопасность в компании. Часть вопросов затрагивает смежные зоны — резервное копирование, непрерывность бизнеса, безопасную разработку, взаимодействие с юристами и PR. Если по ним нет уверенности, лучше уточнить у коллег: точность ответов напрямую определяет пользу результата. Рисунок 7. Пример заполненного профиля организации Заполнив все поля, можно переходить к следующему шагу. Для этого нажмите кнопку «Посмотреть показатели по отрасли».Построение бенчмаркаВ следующем разделе нам становится доступен бенчмарк, отражающий индекс антихрупкости и оценку в разрезе стратегий антихрупкой ИТ-архитектуры в среднем по отрасли. В качестве примера мы выбрали сферу деятельности «финансовый сектор». Рисунок 8. Экспресс-оценка показателей киберустойчивости по отрасли Ниже приводится оценка по стратегиям в табличном виде. Рисунок 9. Индекс антихрупкости в разрезе стратегий и практик по отрасли Прохождение опросаДля расчёта своего индекса антихрупкости пользователю предлагается пройти опрос по 100 практикам, каждая из которых имеет пять вариантов ответа:«Да» (выполняется системно).«Частично» (с ограниченным охватом).«Нет» (не выполняется или выполняется ad hoc, т. е. разово или под конкретную задачу).«Неприменимо» (не используется в организациях данного типа). Этот ответ следует выбрать, если, например, в организации нет такого процесса или системы. При выборе этого варианта метрика исключается из расчёта.«Не знаю» (затрудняюсь оценить). Метрика исключается из расчёта. Рисунок 10. Опрос в рамках стратегий и практик Результат отображается сразу после ответа на последний вопрос. Для расчёта индекса необходимо выбрать «Показать результаты». В том случае, если не все практики были оценены, появится окно с предупреждением и расчёт будет проведён с ограничениями. Рисунок 11. Предупреждение пользователя Оценка результатовНа вкладке «Результаты» отображается текущий уровень киберустойчивости организации, а также сопоставление этого уровня с показателями по отрасли в виде шкалы и радарной диаграммы («диаграммы-паука»). Рисунок 12. Экспресс-оценка киберустойчивости в виде шкал Рисунок 13. Экспресс-оценка киберустойчивости в разрезе стратегий При сравнении учитываются только критерии, по которым даны ответы. Ознакомиться с ними можно ниже в табличном виде. Рисунок 14. Оценка антихрупкости в разрезе доменов — групп практик Информацию по экспресс-оценке киберустойчивости организации можно скачать в виде готового отчёта. Он доступен в формате PDF и представляет собой готовый буклет для ознакомления в электронном виде или печати на бумаге. Рисунок 15. Выгрузка готового отчёта Рисунок 16. Фрагмент отчёта экспресс-оценки киберустойчивости организации ВыводыАнтихрупкость сегодня — ключевая стратегия выживания и роста компаний в условиях постоянных рисков: кибератак, ухода вендоров, сбоев инфраструктуры, регуляторных изменений и т. п. Она не заменяет классическую ИБ — она дополняет её способностью пережить успешную атаку.В современном ИТ‑ландшафте недостаточно просто держаться на плаву, нужно заранее готовиться к тому, чего нельзя предсказать. Именно поэтому антихрупкость становится центральным элементом зрелой ИТ‑стратегии и обязательным ориентиром при проектировании архитектуры, управлении инцидентами и планировании цифровой трансформации.Компания «Инфосистемы Джет» переводит концепцию антихрупкости на язык конкретных инженерных и управленческих решений. Она даёт бизнесу рабочие инструменты — собственный Фреймворк антихрупкой ИТ‑архитектуры, помогающий выстроить понятный путь от стратегии к конкретным действиям, и Индекс антихрупкости, который помогает увидеть, насколько компания реально готова к сбоям, атакам и внезапным переменам.Компания планирует и далее развивать Фреймворк: адаптировать его к специфике различных отраслей, разработать вариативные сценарии применения в зависимости от контекста.Достоинства:Открытая методология, доступная любому пользователю без оплаты и регистрации.Каскадная, понятная архитектура с чёткой логикой: семь стратегий достижения антихрупкости, 10 принципов, 33 домена и 390+ практик.Наличие веб-сервиса для оценки антихрупкости ИТ-архитектуры, в котором прохождение полного опроса по 100 критериям оценки занимает в среднем 20 минут.Возможность ознакомиться с показателями антихрупкости в среднем по отрасли.Представление результатов оценки в графическом и табличном формате.Формирование готового отчёта по итогам экспресс-оценки киберустойчивости с возможностью его выгрузки на компьютер.Недостатки:Ценность фреймворка сложно понять, если предварительно не ознакомиться с теорией антихрупкой ИТ-архитектуры.Для точной оценки индекса антихрупкости рекомендуется располагать полной информацией о деятельности компании и не пропускать ни одного критерия оценки. По уровню детализации Фреймворк антихрупкой ИТ-архитектуры относится к стратегическому и методическому уровню. Детальные технические регламенты, архитектурные стандарты, требования к настройке конкретных систем должны разрабатываться на следующем уровне детализации.Читать далее
×