В этом обзоре будут собранны интересные вещи, обнаруженные в то или иное время, но по разным причинам не исследовшиеся целиком (или не заслуживающие такого исследования). Вообщем полезно/бесполезные вещи/рассуждения на разные темы. Сегодня я раскажу о таких темах:
  • Как с помощью антивируса обойти firewall
  • Некоторые интересные методы автозагрузки
  • Добавляем свои настройки в аутпост
  • Скрытие бекдора на сетевом уровне
Основной темой данного обзора станут продукты компаний, лидирующих в своём секторе - Agnitum Outpost Firewall и антивирус DrWeb. Люди веруя в комплексную защиту, часто забывают что лучшее враг хорошего и в попытках максимально обезопасить себя ставят кучу продуктов, возможно лучших в своём классе, однако своместно превращающих компьютер в друшлаг. В этом обзоре будет представленно самое яркое проявление данной болезни - обход фаера с помощью антивируса.

Trash#0. Как с помощью антивируса обойти firewall
Хочется отметить что данный совет относится только к связке Agnitum Outpost и DrWeb (на других не тестировал - но скорее всего прокатит на фаерах, которые loopback по дефолту разрешают). В DrWeb есть интересный компонент - SpIDer Mail - компонент для проверки почты на вирусы. Давайте посмотрим каким же макаром эта игрушка работает. Очевидно что этот компонент перехватывает сетевые функции. Не буду дальше терзать ваше любопытство, запустите Sporder.Exe из MS SDK и вы увидите примерно такую картину:

 

Двойной шелчёк - и вот где правда:

Итак что же это ? DrWeb осуществляет перехват трафика за счёт так называемых Winsock SPI (не путайте с API=) Посмотрите на базовую концепцию winsock:

Как происходит работа например функции send ? Итак приложение вызывает эту функцию из ws2_32.dll. Для начала вызывается функция WSASend внутри этой же бибилиотеки (это называется косвенное соответвие). Потом, если для протокола присутвует Transport Service Provider вызывается его функция WSASend - тк TSP может быть несколько - они называются Layred - то каждый вызывает туже функцию нижележащего - и так пока не дойдёт до базового поставщика

который и возвращает управление в ws2_32.dll. Таким образом библиотека DrWeb работает на транспортном уровне Winsock - решение интересное - во первых не надо писать драйвер - все происходит в user mode, во вторых сетевых приложений, которые общаются с драйверами протоколов напрямую, минуя winsock еденицы - и почтовики явно к ним не относятся, и наконец в рунете очень мало (вернее совсем нету=) информации о WinSock SPI. Какими же замечательными своиствами должна обладать библиотека WinSock SPI ? Она должна содержать внутри реализацию для 30 функций winsock - хотя в библиотеке функций много, но все они так или иначе соответвуют этим 30 функциям косвенно.

Впринципе можно было бы реализовать всё через проверку данных, отправляемых через WSASend, WSARecv - но в danilov Labs поступили несколько иначе (хз почему). Они перенаправляют функцию WSAConnect на loopback адрес - в результате почтовик работает с локальным почтовым сервером - вместо реального - естественно что этим локальным сервером и является SpIDer Mail - который в свою очередь перенаправляет провернные данные на почтовый сервер.

Ниже предстваленна схема по которой происходит данный обмен:


Таким образом напищем простенькую программку для работы по SMTP протоколу - и попытаемся отправить письмо с помощью компьютера, на котором работают DrWeb и Agnitum Outpost. Скриншот ниже наглядно демонстрируют этот процесс (drweb.exe - это и есть наш мыльный троян):

А вот и майл сессия:

220 mail.ru ESMTP Sun, 09 Jan 2005 08:54:32 +0300
HELO bla.ru
250 mx1.mail.ru Hello bla.ru [198.116.144.15]
MAIL FROM:<[email protected]>
250 OK
RCPT TO:<[email protected]>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) 
Hello world =)

.
250 OK 
QUIT
221 mx1.mail.ru closing connection

Угадайте, какую строчку добавил DrWeb =)

Таким образом разрешая loopback соединения не забывайте о том что троянская программа запросто может создать тунель через доверенный процесс. Ещё одна причина отказаться от дефолтовых настроек, которые предлагает Agnitum.

Trash#1. Интересные места для автозагрузки

Незнаю почему, но большая часть троянов/вирей любит тупо пихать себя в HKLM\Software\Microsoft\Windows\CurrentVersion\Run - однако есть и более лакомые места для автозапуска. Одно из них HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution - в этом разделе при вызове функции CreateProcess ищется подраздел с именем запускаемой программы, но без пути (те подраздел должен содержать только имя файла), там ищется ключ Debugger и если он присутвует - тогда запускается "отладчик", которому в качестве параметров передают имя запускаемой программы. Вообщем как вы поняли - мы можем спокойно запускать всё что угодно вместо чего угодно.

В приложении вы найдёте код, который переносит все программы из ключа HKLM\Software\Microsoft\Windows\CurrentVersion\Run в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution (те при загрузке системы - ваша программа стартует по любому), и перед загрузкой запускает все приложения, что бы эмулировать нормальную работу.

Единственная тонкость - вы должны удалить этот ключ перед тем как запустить оригинальный процесс - иначе ваша программа запустится снова - и войдёт в бесконечный цикл =)

Note: я думаю что большинство наших читателей прочитали 29A#8 и увидели в нём статью GriYo на эту же тему. Что бы эта заметка не выглядела Copy&Paste хочется сказать что данный метод загрузки программы описанн в книге Соломона и Руссинович Inside Windows2k в главе посвящённой процессам, а так же задокументирован в SDK.

Кстати рекомендую всем скачать программку AutoRuns от того же Марка Руссиновича - http://www.sysinternals.com - которая вам покажет множество интересных мест откуда вы можете загружать свои программы (ключ, обсуждаемый в этой заметке туда по счастью не входит=)

Trash#2. Добавляем свои настройки в аутпост

Не интересует добавление своих настроек в firewall ? Сразу после установки Outpost, когда я увидел предопределённые правила для программ меня сразу же заинтересовала возможность добавить предопределение для своего приложения...

Например что бы аутпост предложил пользователю создать правило на основе стандартных. Это достигается с помощью файла preset.lst (формат файла предельно прост), например можно испугать юзера подправив предопределение для ie:

[Internet Explorer]
VisibleState: 0
Exe:
Internet Explorer, iexplore.exe
DefaultState: 1
RuleName: Win32.Troyan Downloader connection
Protocol: TCP
RemotePort: 80-83
Direction: Outbound
AllowIt

Таким образом вы можете показать юзеру окошко не создать правило "на основе другие" а например создать правило Windows Update.... социалльная инжинерия понимаешь ли... пользователь (особенно не искущённый), видя что аутпост знает об этой программе что-то такое хрошее, а так же знакомая иконка и имя исполняемого файла - сыграют своё грязное дело ;)

Таким образом вы можете показать юзеру окошко не создать правило "на основе другие" а например создать правило Windows Update.... социалльная инжинерия понимаешь ли... пользователь (особенно не искущённый), видя что аутпост знает об этой программе что-то такое хрошее, а так же знакомая иконка и имя исполняемого файла - сыграют своё грязное дело ;)

Правим конфиги Outpost

Конфиг аутпоста состоит из 2-х файлов: с расширениями .cfg и .ini (имя файла конфигурации можно получить из ветки реестра - HKLM\Software\Agnitum\Outpost Firewall\General\ - параметр ConfigFileName). Файл cfg для нас пока что особого интереса не представляет - аутпост где-то хранит его контрольную сумму и при изменение начинает бить алярму, что де его зохакали, однако мы можем спокойно править ini файл. В частности интересный параметр (вообще обратите внимание на этот файл - внутри много настроек, которые вызовут улыбку на лице =):

[Components]
ControlMode=число

Как можно догадаться этот параметр отвечает за контроль компонентов - что бы его отключить надо ControlMode=0 - и всё =)

В версии 2.5 появились более продвинутые настройки - в частности контроль скрытых процессов и контроль доступа к памяти:

         [Components]
         ControlMode=2
         HiddenProcMode=2
         WriteProcMemControl=1
       

Эти строки соответвуют таким настройкам, не очень желательным нашим вредным программам:

Кроме того при попытке изменить память процесса аутпост ругается вот таким вот нехорошим сообщением:

Немножко изменив эти настройки:

[Components]
ControlMode=0
HiddenProcMode=0
WriteProcMemControl=0
Мы получаем милую глазу картину, великий и могучий сдался перед нашим блокнотом:

Или например файл - protocls.lst - в этом файле находится список протоколов для составления глобальных правил - причём протоколы можно закоментить с помощью # - тогда их нельзя будет использовать для создания новых правил - например:

[Transport layer protocols]
0,RAWSOCKET,Raw socket
#1,ICMP,Internet Control Message Protocol
#2,IGMP,Internet Group Management Protocol
ICMP и IGMP исчезнут из набора для составления правил

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

Trash #3.Скрытие бекдора на сетевом уровне

Итак вы установили руткит, который естесвенно включает в себя бекдор. На порутанном хосте мы неуязвимы и невидимы...а вот по сети ? Что если админ сканирует сеть сканерами безопасности и удивиться, обнаружив открытый 31337 порт ? Или просто кто-нить будет сканить сеть наткнётся на бекдор ? Если уж и быть невидимым - то везде!

Во первых вам естесвенно не обязательно держать порт открытым всё время. Порт может открываться и закрываться по расписанию или по определённому событию. Думаю всем знакомы такие вещи как icmp-wake-up бекдоры - в случае получения определённого icmp пакета бекдор "пробуждается" и открывает порт. Кроме открытия порта в ответ на специальный пакет возможно открытие по расписанию...или основываясь на каком-либо событии в системе. Естесвенно открывая порт на время мы только снижаем наши шансы быть обнаруженными по сети. Но иногда хочется большей невидимости...

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

  • [+] легко реализуется. В сети есть куча примеров. На простеньких фаерах нет претензий к ICMP трафику.
  • [-] В серьёзных девайсах если ICMP и пропускается - то подвергается полной пересборке. Т.е. ваши данные отправленные в ICMP пакете до получателя не дойдут
С другой стороны мы можем работать при помощи сниффера - собирая весь трафик и отфильтровывая нужные нам пакеты. Этот способ так же не лишён недостатков:
  • [+] трафик можно будет пускать только по "легальным" портам, либо вообще тунелируя на прикладном уровне
  • [-] существуют довольно развитые средства обнаружения снифферов
Раширяя представления о предыдущем пункте можно наткнуться на интересную технику использования SYN пакета для авторизации. Как все замечали - SYN пакеты обычно не несут никакой полезной нагрузки. Однако мы можем загнать в такой пакет данные - таким образом если в SYN пакете бекдор получает инициализирующую строку (пароль), значит он шлёт SYN-ACK ответ, если же приходит пустой SYN - тогда в ответ RST и досвидание. Таким образом - если в традиционном бекдоре используется авторизация, после установки TCP соединения, то в этом варианте мы, на стадии первого пакета, знаем что и кто к нам стучится. Минусы этого способа такие же как и у предыдущего, а вот плюсов гораздо больше - в часности мы обламываем сканеры сети и прочих ненужных гостей, которые шлют пустые SYN пакеты.

Ну и наконец - пожлауй самый сложный тип - это захват контроля над уже установленным соединением - в часности такие вещи подойдут для веб серверов - в случае получения уже специально сформированного HTTP пакета ( get /backdoor/ =) - мы обрубаем соединение на нашей половине с "официальным" держателем порта и начинаем общаться по уже установленному соединению. Минусы - мы можем затратить много ресурсов на обработку трафика...

Подводя итог этой короткой заметки хочется сказать что хороший руткит должен быть невидимым не только на локальном компьютере но и по сети - не должно быть никаких открытых наружу портов. Весь трафик должен туннелироваться на прикладном уровне (те не в ICMP - а в HTTP/DNS/FTP/ICQ ... etc), естесвенно тунелинг не должен заключаться в простой отправке пакетов по 80 порту - надо закладывать свои данные в струтуры протоколов прикладного уровня - т.к. они наиболее тяжело поддаюся анализу - особенно "разговорные" протоколы - типа SMTP или FTP. Используя все эти советы можно оставаться полностью невидимым....а вы всё ещё не верите в федеральный бекдор в вашей операционной системе?

The end

Автор: said /27.02.05/ ©

Mazafaka.Ru - E-Zine - 2005 ©