Перейти к содержанию

Recommended Posts

alisa_sh

Очередной "тест АВ продуктов" из просторов интернета вызывает привычный набор эмоций, даром что источник в этот раз именитый.

http://secunia.com/blog/29/

Тестировать "способность детектировать уязвимости" в рамках файлового сканирования самописных proof-of-concept - это еще круче, чем тестировать сигнатурное сканирование на коллекции неопознанных "каких-то там вирусов" без дат и источников.

Для тех кто не в теме, упрощенно поясню: детектировать поки - это примерно как детектировать хакерские утилиты (типа сканера), а детектировать поки файловым сканированием - это примерно как детектировать вирусы для мобильников антивирусом для ПК.

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

Вообще у меня есть гипотеза, что если любой тест равноранговых продуктов (т.е из единого конкурентного поля) показывает отрыв одного из представителей больше чем на 20-30%, то это автоматическое свидетельство аффилированности. Либо прямой (=покупка результата, это не эстетично), либо косвенной (=необъективность методологии, в частности случайная или умышленная ее "заточенность" под конкретный продукт).

Просто потому что в условиях игры на одном и том же поле у продуктов нет возможностей - а по большому счету и поводов - СИЛЬНО обходить конкурентов. В условиях рыночной конкуренции любое нововведение быстро перенимается всеми. И если отрыв все-таки происходит, то это уже совсем другой рынок и другое поле.

С другой стороны, если не застревать на этапе критицизма, то возникают новые интересные мысли. Например о том, что "защитные" продукты действительно не занимаются эксплойтами в той степени, в которой последние того заслуживают. Если оглядеть ретроспективно вирусную ситуацию этого года, оказывается, что большинство более-менее серьезных кейсов (приближенных к эпидемиям) произошли именно от эксплуатации уязвимостей (SWF exploits etc.). А ведь это только публичные кейсы, помимо них есть еще и приватные сплоеты (пардон, нераскрываемые техники), через которые распространяется более серьезная и штучная малварь.

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


Ссылка на сообщение
Поделиться на другие сайты
vaber
Тестировать "способность детектировать уязвимости" в рамках файлового сканирования самописных proof-of-concept - это еще круче, чем тестировать сигнатурное сканирование на коллекции неопознанных "каких-то там вирусов" без дат и источников.

Для тех кто не в теме, упрощенно поясню: детектировать поки - это примерно как детектировать хакерские утилиты (типа сканера), а детектировать поки файловым сканированием - это примерно как детектировать вирусы для мобильников антивирусом для ПК.

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

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

Вообще у меня есть гипотеза, что если любой тест равноранговых продуктов (т.е из единого конкурентного поля) показывает отрыв одного из представителей больше чем на 20-30%, то это автоматическое свидетельство аффилированности. Либо прямой (=покупка результата, это не эстетично), либо косвенной (=необъективность методологии, в частности случайная или умышленная ее "заточенность" под конкретный продукт).

Просто потому что в условиях игры на одном и том же поле у продуктов нет возможностей - а по большому счету и поводов - СИЛЬНО обходить конкурентов. В условиях рыночной конкуренции любое нововведение быстро перенимается всеми. И если отрыв все-таки происходит, то это уже совсем другой рынок и другое поле.

Хм..странная гипотеза :). Неужели Вы полагаете, что по всем важным параметрам продукты одинакового класса имеет близкую эффективность? В общем подождем тест на активное - тогда думаю Вашу гипотезу Вы отвергнете сами ;)

С другой стороны, если не застревать на этапе критицизма, то возникают новые интересные мысли. Например о том, что "защитные" продукты действительно не занимаются эксплойтами в той степени, в которой последние того заслуживают. Если оглядеть ретроспективно вирусную ситуацию этого года, оказывается, что большинство более-менее серьезных кейсов (приближенных к эпидемиям) произошли именно от эксплуатации уязвимостей (SWF exploits etc.). А ведь это только публичные кейсы, помимо них есть еще и приватные сплоеты (пардон, нераскрываемые техники), через которые распространяется более серьезная и штучная малварь.

Угу, эксплоитами занимаются "защитные" продукты, а патчами производители уязвимого софта.

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


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

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

Соответственно, из теста есть только два вывода (для людей, которые умеют думать):

1. Нужно ставить патчи на уже найденные дырки (патч-менеджмент).

2. Нужно ставить HIPS для минимизации ущерба от эксплуатации 0-day уязвимостей.

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


Ссылка на сообщение
Поделиться на другие сайты
vaber
2. Нужно ставить HIPS для минимизации ущерба от эксплуатации 0-day уязвимостей.

Согласен, хипс ставить нужно, но насколько эффективно он защитит от эксплуатации этих самых 0-day? Имею ввиду хипс в целом, а не конкретный продукт.

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


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович
Согласен, хипс ставить нужно, но насколько эффективно он защитит от эксплуатации этих самых 0-day?

HIPS не защищают от экплуатации 0-day уязвимостей. Они защищают от последствий успешной эксплуатации уязвимости. Разные HIPS продукты- с разной степенью успешности.

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


Ссылка на сообщение
Поделиться на другие сайты
vaber
HIPS не защищают от экплуатации 0-day уязвимостей. Они защищают от последствий успешной эксплуатации уязвимости. Разные HIPS продукты- с разной степенью успешности.

Это и имел ввиду - последствия, но написал почему-то эксплуатацию :). Я вообще к чему клонил - к тому, что зачастую теперь используют уязвимости (зеродеи мне пока не попадались) для атаки на сам HIPS, с целью нарушить его работу и тем самым закрепиться в системе.

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


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

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


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович
Это и имел ввиду - последствия, но написал почему-то эксплуатацию

Ну, я же не могу залезть каждому в голову, чтобы понять, кто что _хотел_ написать. Приходится читать прямо с забора! :)

Я вообще к чему клонил - к тому, что зачастую теперь используют уязвимости (зеродеи мне пока не попадались) для атаки на сам HIPS, с целью нарушить его работу и тем самым закрепиться в системе.

Каждый программный продукт имеет уязвимости и ошибки программирования. Какой-то больше, какой-то меньше. Вопрос даже не в этом. Чем более гетерогенна общая среда защиты, тем больше нужно тратить средств и времени для поиска уязвимостей в каждом из продуктов, который может встетиться на пути. Что отсеивает пионэров. А нет их- нет и притока в malware-индустрию новых мозгов.

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


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

  • Сообщения

    • PR55.RP55
      1) По поводу команды: Сбросить атрибуты для все файлов/каталогов в... Это не работает, если не заданы: Группы или пользователи. т.е. нужно проверить не пуст ли список... Если пуст:  прописать пользователя. И только после этого можно сбросить атрибуты... 2) При проверке ЭЦП по F6 ... Если неполадки с сетевым оборудованием, или службами отвечающими за доступ к сети... uvS видит: Сеть есть... и начинает проверять файлы. А по сути сети нет. т.е. здесь нужен таймер.: Если в течении определённого времени нет результата - то проверять ЭЦП локально ( с соответствующей записью в Лог )   Не ждать, как сейчас 100 500 часов. 3)  Проверка занимает излишне много времени в ситуации: Ошибка  [Не удается построить цепочку сертификатов для доверенного корневого центра. ]
      Ошибка  [Цепочка сертификатов обработана, но обработка прервана на корневом сертификате, у которого отсутствует отношение доверия с поставщиком доверия. ] uVS натыкается на такой файл и думает... думает...
    • PR55.RP55
      1) Если оператор применил фильтр  [V]  Известные. То при применении команды: F6   проверять только оставшиеся в списке файлы. Это на порядок ускорит проверку.  Нужно проверить всё ? Сними чек-бокс.  
    • PR55.RP55
      В Инфо. указывать не только время создания\изменения файла но и время создания... Пример:  Система Установлена 2018  > Каталог создан в 2020, а файл в каталоге  2021  
    • santy
      как только заработает функция "выполнить запрос по критерию" - все отфильтрованные объекты будут на виду у оператора, и скорее всего, помещены в отдельную категорию. Кстати, всех участников данного форума (помимо проходящих мимо спамеров) поздравляю с Новым 2021 годом!
    • PR55.RP55
      1) Добавить в settings.ini  настройку: "Выделять все неизвестные ЭЦП" Таким образом все ЭЦП которых нет в базе:  wdsl будут на виду. Это  позволит пополнять базу wdsl и сразу акцентировать внимание оператора. 2) Добавить в settings.ini  настройку: Все файлы с неизвестной ЭЦП  помечать, как подозрительные. Или создать отдельную категорию: "Неизвестные ЭЦП" 3) В Инфо. файла помещать информацию типа: Действительна, подписано CAVANAGH NETS LIMITED Найдено файлов: 1 wdsl   [ - ] --------------- Действительна, подписано Mozilla Corporation Найдено файлов: 80 wdsl   [ + ]  
×