KHOBE – 8.0

И снова матусешки "порадовали" пользователей.
Беглый перевод:
[QUOTE][B]Цель работы
[/B]
Основная часть ПО использует стандартные хуки. А некоторые "изделия" до сих пор строят свою защиту в основном на хуках пользовательского режима, которые, как Вы узнаете далее, работают некорректно. Многие производители решили модифицировать ядро механизма системного вызова. Они изменить содержимое таблицы дескрипторов системного вызова (SSDT хукинг). Другие используют различные виды хуков ядра, например, изменяя код ядра напрямую.

Основная цель этого документа заключается в демонстрации метода атаки, который называется "переключатель аргумента" или атака KHOBE, что позволяет вредоносному коду обойти механизмов защиты. Такая атака эффективна как против пользовательского режима, так и режима ядра. Поскольку в режиме пользователя хуки намного легче обойти, то мы сконцентрируемся на рассмотрении обхода хуков только в режиме ядра. Далее мы продемонстрируем методы атаки на SSDT хуки, которые на данный момент являются самими распространенными в защитном ПО. Тем не менее, методы атаки не требуют особых изменений для успешной борьбы с другими видами уязвимости ядра или пользовательского режима.

Для тестирования мы разработали движок KHOBE (Kernel HOok Bypassing Engine), который упрощает написание эксплоита. С KHOBE нам удалось в сравнительно короткий срок убедиться, что представленные уязвимости являются реальной проблемой для многих известных продуктов безопасности.
. . .
[B]Уязвимое защитное ПО (100% из протестированных)[/B]

- 3D EQSecure Professional Edition 4.2
- avast! Internet Security 5.0.462
- AVG Internet Security 9.0.791
- Avira Premium Security Suite 10.0.0.536
- BitDefender Total Security 2010 13.0.20.347
- Blink Professional 4.6.1
- CA Internet Security Suite Plus 2010 6.0.0.272
- Comodo Internet Security Free 4.0.138377.779
- DefenseWall Personal Firewall 3.00
- Dr.Web Security Space Pro 6.0.0.03100
- ESET Smart Security 4.2.35.3
- F-Secure Internet Security 2010 10.00 build 246
- G DATA TotalCare 2010
- Kaspersky Internet Security 2010 9.0.0.736
- KingSoft Personal Firewall 9 Plus 2009.05.07.70
- Malware Defender 2.6.0
- McAfee Total Protection 2010 10.0.580
- Norman Security Suite PRO 8.0
- Norton Internet Security 2010 17.5.0.127
- Online Armor Premium 4.0.0.35
- Online Solutions Security Suite 1.5.14905.0
- Outpost Security Suite Pro 6.7.3.3063.452.0726
- Outpost Security Suite Pro 7.0.3330.505.1221 BETA VERSION
- Panda Internet Security 2010 15.01.00
- PC Tools Firewall Plus 6.0.0.88
- PrivateFirewall 7.0.20.37
- Security Shield 2010 13.0.16.313
- Sophos Endpoint Security and Control 9.0.5
- Trend Micro Internet Security Pro 2010 17.50.1647.0000
- Vba32 Personal 3.12.12.4
- VIPRE Antivirus Premium 4.0.3272
- VirusBuster Internet Security Suite 3.2
- Webroot Internet Security Essentials 6.1.0.145
- ZoneAlarm Extreme Security 9.1.507.000
. . .
[B]Заключительные замечания и заметки [/B]

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

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

Мы показали, как "переключатель аргумента" работает на примере SSDT хукинга. Тем не менее, этот метод также может быть использован для других видов хукинга. Необходимо только несколько общих условий. Нападение может функционировать и на хуках, которые:
работают на низком IRQL с включенным планировщиком, это условие теоретически не требуется на многопроцессорных системах, где атакующий и ложный поток могут выполняться на разных процессорах одновременно;
принимают хендлы объектов ядра или указателей в пользовательском режиме на часть адресного пространства;
выполняют контроль валидности и безопасности;
вызывают процедуры с оригинальной неизменными значениями важных аргументов.

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

Можно подумать, что при установке второго дополнительного приложения для обеспечения безопасности сможет защитить от атаки "переключатель аргумента". Однако, это только усугубляет ситуацию. Представьте себе, что два приложения для обеспечения безопасности, А и Б, хукнули системный сервизу NtOpenProcess. Когда приложение пытается открыть процесс, исполнение потока перехватывается хуком обработчика установленного драйвера применения Б (это приложение хукнуло сервис, когда он уже была хукнут приложением А).

Если хук обработчика Б не имеет защиты от атаки "переключатель аргумента", то он не дает никаких дополнительных мер безопасности в сравнении с только хуком приложения А. Это может даже создать дополнительный риск безопасности для приложения А. Хук обработчика приложения Б можно назвать хуком обработчика приложения А, но это не обязательно так - если приложение Б вместо этого вызывает оригинальную (немодифицированную) систему обслуживания, то функция операционной системы не имеет значения (за исключением производительности), но приложение А не имеет возможности выполнять проверку системы безопасности.

С другой стороны, если приложение Б хочет сохранить функциональность обработчика хуков приложения А и вызывает его с оригинальными аргументами, то обработчик хука приложения Б уязвимым к атаке "переключатель аргумента", независимо от реализации метода обработчика хуков приложения А. Таким образом, до тех пор, пока А и Б не будут хорошо реализованы и смогут полагаться на друг друга (что довольно маловероятно, т.к. подразумевает сотрудничество двух аналогичных приложений, написанных разными конкурирующими авторами), А или Б будет уязвимо к атаке "переключатель аргумента". Именно поэтому установка более одного защитного ПО на одной машине в настоящее время несёт риск, даже если их поставщики утверждают, что ПО будут совместимы.

[B]Вывод[/B]

Эта статья демонстрирует шаблон атаки известной как атака "переключатель аргумента", которая показывает, что стандартная реализации режима ядра хуков не является безопасной. Эта атака представляет серьезную угрозу, поскольку многие поставщики защитного ПО, а основе реализуют свои функции безопасности на перехвате. Мы протестировали наиболее широко используемое ПО и выяснили, что все они уязвимы. самых популярных решений Сегодня самые распространённое защитное ПО просто не работает...

[/QUOTE]

[url]http://www.matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php[/url]

Это что? крах проактивок и селф дефенсов?
Читаеш такое и невольно думаеш зачем это изобретали.
Неужели все так плохо? Или статья слегка приукрашена?

[QUOTE][B][U]Если[/U][/B] хук обработчика Б не имеет защиты от атаки "переключатель аргумента"...[/QUOTE]

По-умолчанию этой проверки нет. Примечательно что [U]все[/U] популярные производители ПО понадеялись на умолчания. Но как уже ответил Илья, [I]там ничего сложного нет, нужно лишь всё сделать тщательно.[/I]

Как всегда, в ядре не стоит доверять данным полученным с пользовательского уровня?
Приложение хотело одно, а потом перехотело и захотело другое. Посмотрим что скажут вендоры.
А вообще мне кажется проблема сильно приукрашена.

Может и приукрашена, но более трёх десятков проверенных самых распространённых крутых [U]систем защиты[/U] - лежат. И это неукрашающий факт.

[url]http://www.anti-malware.ru/forum/index.php?s=&showtopic=12785&view=findpost&p=104919[/url]

Может проблема и в $$$, но какого более 7 лет [U]никто ничего не делает[/U] по этому поводу? А кто первый нашёл/ придумал/ протестировал и как назвал - это всё лабуда, которая не имеет никакого отношения к безопасности - пользователям от этого не легче, проблема не исчезла, а вендоры и дальше штопают фигню, которая надеется на умолчания...

А может это они так зарабатывают на кулхацкерах?