| RSS



Меню

Bookmark and Share


Статистика
Ваш IP: 3.17.175.167
Вы используете: v





Сейчас на сайте:

Тех поддержка ->

Облако тэгов
ОС видио Tor Обратная сторона антенна 4.6 PHP Эксплоит Windows Server 2008 qip Virtual chroot kernel proc sysctl tune FreeBSD bridge Boot Disk Bluetooth GEO game directx Emulator Python Shell DDoS червь Conficker вирус троян Лаборатория Касперского пиратство apple iPhone ИТ-отрасль Щеголев Microsoft экономический кризис Twitter социальная сеть анонимность Лицензия Open Source ASP.NET MVC уязвимость MySQL база данных файлообмен закон франция пират Skype мобильный Deutsche Telekom Хакер киберпреступник Trend Micro кибератака Германия робот утечка данных персональные данные ноутбук интернет Китай цензура ядро Linux Торвальдс Windows Vista Acer Linux патент браузер Firefox Internet Explorer Opera Net Applications Safari Intel Linux Foundation Moblin Oracle патч банкомат кардер HSM IBM X-Force Cofee сша кибервойна Эстония Dell ИТ-специалист хакерские атаки Pirate Bay контроль кибербезопасность язык программирования The Pirate Bay Пиратская партия утечка информации приговор Mozilla Chrome безопасность Госдума СМИ Windows 8 Баллмер взлом Пентагон ботнет Украина Facebook Cisco cloud Windows XP нетбук торрент музыка биометрический nokia ФБР IP-адрес CIPAV Comcast sms RSA java Google CAPTCHA Symantec спам конфиденциальная информация инсайдер Perimetrix антивирус тест Anti-Malware Windows 7 операционная система Windows провайдер авторское право RapidShare UNIX свиной грипп шантаж дети EFF BluWiki копирайт экстремизм Panda Security cloud computing McAfee Cybercrime Response Unit Bottle Domains HTTPS ICANN студент шпионское ПО Норвегия школьник New York Times XSS YouTube Warner Music кибершпионаж КНДР Ubuntu свободное ПО AMD ATI касперский Россия РФ сервер хостинг фальшивый антивирус Comodo CA Wi-Fi D-Link суд пароль блог фишинг Одноклассники медведев контрафакт мошенник штраф Sony GPS по Gumblar JAVASCRIPT хакеры вредоносное ПО Yahoo ФАС компьютер Софт MPAA кибероружие PandaLabs Red Hat Минкомсвязи сбой ASUSTeK Computer мошенничество Доктор Веб ВКонтакте Cyber-Arc исходный код PCI DSS МВД фильтр порнография BREIN свобода слова Казахстан GEMA Autodesk сисадмин Gmail кредитная карта кибермошенник LiveJournal шифрование криптография Deep Purple банк нанотехнологии Wikipedia zero-day ColdFusion выборы кража данных DNS BIND Android BASIC атака Black Hat Mac OS X Click Forensics Clampi домен фсб Прокуратура Уголовное дело icq Barrelfish киберпреступность Sophos AT&T ошибка Electa Gamma Knife OpenBSD DARPA военные Сайт Visual Studio 2010 .NET Framework 4 Chrome OS электронная почта турция конференция спамер FTC полиция российская ОС Koobface Великобритания БЕЛОРУССИЯ грузия BSA Bittorrent облачные вычисления Azure Европа Dr.Web Билл Гейтс спецслужбы Cryzip Живой Журнал Royal Bank of Scotland смартфон Canonical Pwn2Own F-Secure Symbian Hotmail фильм

Главная » Статьи » Общие Статьи

Обнаружение компрометации ядер Linux и xBSD

Кочевые племена против оседлых форм жизни

Существуют два типа руткитов: первые, внедряясь в систему, создают новые файлы или модифицируют уже существующие, получая управление при каждой загрузке операционной системы. Другие же — вообще не прикасаются к диску, не создают новых процессов, ограничиваясь модификацией оперативной памяти. Естественно, руткиты такого типа умирают при перезагрузке и выглядят не слишком-то жизнеспособными, однако до тех пор, пока дыра, через которую проникает руткит, остается не залатанной, он будет приходить вновь и вновь. Закрытие дыры мало чего изменит, ведь там, где есть одна дыра, найдутся и другие — создателю руткита достаточно переписать несколько десятков строк кода, ответственных за внедрение первичного загрузчика в целевую систему, – и дело сделано.

В распределенных сетях (ботнетах) перезагрузка одного или нескольких узлов — вообще не проблема, к тому же после перезагрузки узел будет инфицирован вновь. Этот факт очень трудно обнаружить, ведь никаких изменений на диске нет! А сетевые соединения современные руткиты скрывают весьма эффективно. Прошли те времена, когда открытые порты обнаруживались тривиальным сканированием с соседней машины. Продвинутые руткиты не открывают никаких портов. Они садятся на сетевой интерфейс, контролируя трафик и модифицируя определенные поля в заголовках TCP/IP-пакетов, значения которых согласно RFC выбираются случайным образом. Скремблер скроет факт модификации (независимо от передаваемых руткитом данных мы получим такое же хаотичное распределение, как и на незараженной машине), а несимметричный шифратор предотвратит декодирование перехваченной информации. Даже если мы заведомо знаем, что руткит есть!

Откуда мы узнаем, что он есть? Объем трафика в норме, никаких изменений на диске не наблюдается (что кардинальным образом отличается от руткитов первого типа, которые обнаруживаются настолько тривиально, насколько это можно себе представить). Загружаемся с LiveCD и проверяем контрольные суммы всех файлов (или просто осуществляем побайтовое сравнение с дистрибутивом). Конечно, для серверов такой способ не очень-то пригоден — их вообще лучше не перезагружать, но сервера, критичные к перезагрузкам, обычно оснащены RAID-массивами с hot-plug'ом. Так что просто вытаскиваем один набор дисков из матрицы, ставим его на другую машину, проверяем контрольную сумму и делаем оргвыводы.

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

Методы борьбы, или была б катана — сделал бы харакири

Прежде чем продвигаться вглубь, сразу выбросим на помойку несколько популярных, но безнадежно устаревших способов борьбы с руткитами. Чтение памяти ядра через /dev/[k]mem (при активом рутките!) — это курам на смех. Поиск следов компрометации при помощи GDB – из той же оперы. Руткиту ничего не стоит отследить обращение к любому файлу/устройству, «вычистив» следы своего пребывания или совершить «харакири» при запуске GDB. Чуть сложнее — ввести в заблуждение GDB, оставаясь при этом активным, живым и здоровым.

Достойных отладчиков ядерного уровня под никсы не существует. Ну, не то, чтобы совсем нет, но в штатный комплект поставки уж точно ни один не входит. Хорошо еще, если установка отладчика не требует перекомпиляции ядра, не говоря уже о перезагрузке. Самих же отладчиков довольно много: NLKD, KDB, LinIce, DDB, и ни один из них не обладает неоспоримыми преимуществами перед остальными. Кстати, для ловли руткитов иметь готовый к употреблению отладчик необязательно. Достаточно написать загружаемый модуль ядра, считывающий и передающий на прикладной уровень все критичные к перехвату структуры данных вместе с машинным кодом (естественно, ядро должно быть скомпилировано с поддержкой модульности). Что это за данные — мы сейчас выясним.

Магические аббревиатуры — GDT, LDT, IDT

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

Начнем с простого. С таблиц глобальных/локальных дескрипторов (Global/Local Description Table или, сокращенно, GDT/LDT), хранящих базовые адреса, лимиты и атрибуты селекторов. Чем они могут помочь руткиту? Ну, кое-чем могут. Linux/xBSD используют плоскую модель памяти, при которой селекторы CS (код), DS (данные) и SS (стек) «распахнуты» на все адресное пространство: от нуля до самых верхних его окраин. Создание нового селектора с базой, отличной от нуля, с последующей его загрузкой в один из сегментных регистров существенно затрудняет дизассемблирование руткита, особенно тех экземпляров, что выдраны из памяти чужой машины. Таблицы дескрипторов в распоряжении реверсера нет и не будет (руткит умер). Грубо говоря, мы вообще не можем определить, к каким данным осуществляется обращение, ведь база селектора неизвестна! Реверсеров и сотрудников антивирусных компаний такие руткиты просто доводят до бешенства, затягивая анализ, а вместе с ним и приготовление «вакцины».

Побочным эффектом этого антиотладочного приема становится появление новых селекторов в таблице дескрипторов, которых там никогда не наблюдалось ранее. Отладчики ядерного уровня позволяют просматривать таблицы дескрипторов в удобочитаемом виде, но при активном рутките пользоваться отладчиком не рекомендуется. Лучше написать свой загружаемый модуль ядра, считывающий содержимое таблицы дескрипторов командами SGDT/SLDT, описанными (вместе с форматами самих таблиц) в документации на процессоры Intel и AMD.

Огромное количество руткитов модифицирует таблицу дескрипторов прерываний (Interrupt Description Table или, сокращенно, IDT), позволяющую им перехватывать любые прерывания и исключения, в том числе и системные вызовы, реализованные на некоторых системах именно как прерывания. Но о сисколлах мы еще поговорим, а пока лишь отметим, что модификация IDT позволяет руткиту перехватывать обращения к страницам, вытесненным на диск (при обращении к ним возникает исключение Page Fault). А также перехватывать другие исключения, например, общее исключение защиты (General Protection Fault), отладочное и пошаговое исключение (отличный способ борьбы с отладчиками), не говоря уже о прерываниях, поступающих от аппаратных устройств — клавиатуры, сетевой карты и прочего оборудования, прямое обращение к которому очень полезно для сокрытия «преступной» деятельности.

Таблица прерываний, отображаемая отладчиками в удобочитаемом виде, может быть прочитана процессорной командой SIDT, что намного надежнее, поскольку перехватить ее выполнение руткит уже не в состоянии.

Практическая магия системных вызовов

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

В зависимости от типа и версии ОС системные вызовы реализуются по-разному. Самый древний механизм — это далекий вызов по селектору семь, смещение ноль — CALL FAR 0007h:00000000h (или, то же самое, но в AT&T синтаксисе — lcall $7,$0). Он работает практически на всех x86-клонах UNIX'а, однако практического значения не имеет, поскольку им пользуются только некоторые ассемблерные программы в стиле «hello, world!», ну и… вирусы, также написанные на ассемблере.

Стандартом де-факто стал программный вызов прерывания 80h (INT 80h), работающий как в Linux, так и во FreeBSD. Как руткит его может перехватить? Посредством модификации таблицы дескрипторов прерываний, переназначая вектор 80h на свой собственный код. Однако это не единственный вариант. Стандартно INT 80h передает управление на функцию system_call, адрес которой можно определить по файлу System.map, если он, конечно, не удален администратором по соображениям безопасности, — тогда руткит либо читает вектор 80h через SIDT, либо находит system_call эвристическим путем, поскольку она, как и любой другой обработчик прерывания, содержит довольно характерный код. Вставив в начало (или середину) этой функции команду перехода на свое тело, руткит будет получать управление при всяком системном вызове. Следовательно, мы должны считать код функции system_call из памяти, сравнив его с оригиналом, который можно позаимствовать из неупакованного ядра, выдернутого из дистрибутивного диска (как это сделать, мы уже неоднократно рассказывали).

После выполнения системного вызова управление получает другая интересная функция — ret_from_sys_call, идущая следом за system_call и также, как и system_call, присутствующая в System.map. Ее перехватывают многие руткиты, что вполне логично, поскольку «вычистить» следы своего пребывания лучше всего после отработки системного вызова (а не до него). Популярные руководства по поиску руткитов об этом почему-то забывают, а зря! Функцию ret_from_sys_call следует проверять в первую очередь, сравнивая ее код с кодом оригинальной ret_from_sys_call, ну или просто дизассемблируя его на предмет наличия посторонних переходов.

Начиная с версии 2.5, ядро Linux поддерживает механизм быстрых системных вызовов, реализуемый командами SYSENTER/SYSEXIT (Intel) и SYSCALL/SYSRET (AMD). Он существенно облегчает перехват и делает его трудно заметным. Команда SYSENTER передает управление с 3-го кольца прикладного уровня на ядерный уровень, используя специальные MSR-регистры, а конкретно: IA32_SYSENTER_CS содержит селектор целевого сегмента, IA32_SYSENTER_EIP — целевой адрес перехода, IA32_SYSENTER_ESP — новое значение регистра ESP при переходе на ядерный уровень. При этом селектор стека равняется (IA32_SYSENTER_CS + 08h). SYSCALL работает практически аналогичным образом, только MSR регистры другие: STAR, LSTAR и CSTAR (подробнее об этом можно прочитать в описании самой команды SYSCALL в спецификации от AMD, ну или от Intel, с учетом, что она поддерживает эту команду в той же манере, в какой AMD поддерживает SYSENTER).

Суть в том, что целостность MSR регистров долгое время никто не проверял – чем руткиты с успехом и воспользовались, изменяя MSR-регистры таким образом, чтобы управление получал не системный обработчик, а код руткита со всеми вытекающими отсюда последствиями. Далеко не все отладчики отображают содержание MSR регистров. Но это легко осуществить с ядерного уровня командой RDMSR, которую руткит также не может перехватить, а потому все его махинации с MSR регистрами будут немедленного разоблачены. Естественно, помимо проверки MSR-регистров (они должны указывать на тот же самый системный обработчик, что и в заведомо неинфицированной системе с той же самой версией ядра), мы должны проверить код самого обработчика. Он может быть изменен руткитом для перехвата управления без модификации MSR (впрочем, одно другому не мешает, и многие руткиты используют гибридный вариант).

Поддержка SYSENTER/SYSCALL не отменяет INT 80h, по-прежнему присутствующую в ядре и вызываемую из старых прикладных библиотек некоторых ассемблерных программ, ну и, конечно, вирусов, работающих на прикладном уровне! Так что руткитам теперь приходится перехватывать и то, и другое, хотя перехват SYSENTER/SYSCALL намного более перспективен (INT 80h используется все реже и реже).

А вот разработчики FreeBSD от INT 80h отказываться пока не собираются, и хотя существует патч от David'а Xu, написанный в конце 2002 года и переводящий систему на SYSENTER/SYSCALL (people.freebsd.org/~davidxu/sysenter/), по умолчанию он не включен в стабильный релиз. Впрочем, сторонние составители дистрибутивов его активно используют (взять, к примеру, DragonFlyBSD).

Официальный дистрибутив FreeBSD 7.0 на 3-х DVD для архитектуры x86.

Модификация таблицы системных вызовов

Указатели на системные вызовы перечислены в таблице sys_call_table, адрес которой можно найти все в том же System.map или вычислить эвристическим путем (удаление System.map'а не слишком-то усиливает безопасность).

Подмена указателя на оригинальный системный вызов указателем на код руткита — это классика перехвата. Элементарно обнаруживается путем сравнения оригинальной таблицы системных вызовов, выдернутой из неупакованного ядра дизассемблером, с ее «живой» сестрицей, прочитать которую можно либо отладчиком, либо «руками» – командой mov, вызываемой из загружаемого модуля ядра. Оба способа абсолютно ненадежны и выявляют только пионерские руткиты. «Зверюшки» посерьезнее сбрасывают страницы, принадлежащие таблице системных вызовов, в NO_ACCESS. В результате, при обращении к ним процессор выбрасывает исключение, подхватываемое руткитом, который смотрит, откуда пришел вызов на чтение — если это функция system_call, то все ОК, если же нет, то руткит возвращает подложные данные, и таблица системных вызовов выглядит, как сама невинность. Конечно, перед чтением можно проверить атрибуты страницы, но весь фокус в том, что функция определения атрибутов страниц реализована как системный вызов, находящийся в той же самой таблице, контролируемой руткитом. Упс! Приехали! Ладно, перед чтением мы назначим свой собственный обработчик исключений, который выручит нас только в том случае, если руткит не модифицировал IDT. Решение заключается в «ручном» разборе страничного каталога, формат которого описан в руководствах по системному программированию на процессоры Intel/AMD и представляет собой намного более простую задачу, чем это кажется поначалу.

Естественно, кроме таблицы системных вызовов необходимо проверить и целостность самих системных вызовов, помня о том, что руткиты могут внедрять команду перехода на свое тело не только в начало функции системного вызова, но также в ее конец или середину, хотя для этого им придется тащить за собой дизассемблер длин инструкций. Тем не менее, «серединный перехват» — стандарт де-факто для всех серьезных руткитов.

Дайте мне мыло, веревку или… дропер!

Сотрудники антивирусных компаний получают вирусы/руткиты из трех основных источников. Первый – свои собственные HoneyPot'ы, второй – малварь, присланная коллегами (другими антивирусными компаниями), третий (самый плодотворный) — файлы, полученные от пользователей.

В какой-то момент вирусописателям надоело, что их творения разносят в пух и прах в считанные дни, когда на создание руткита и его отладку уходят многие недели — обидно, да? Вот они и стали искать пути, как затруднить анализ малвари, и ведь нашли! Специальная программа, называемая дропером (от английского to drop – бросать), «сбрасывает» основное тело малвари на целевой компьютер, при этом оно шифруется ключом, сгенерированным на основе данных о конфигурации системы, и наружу «торчит» только расшифровщик (зачастую, полиморфный). Как нетрудно догадаться, малварь такого вида работает только на том компьютере, на который она попала «естественным» путем, а всякая попытка запуска ее на другой машине ничего не дает! Ничего, абсолютно!

Чтобы проанализировать малварь, необходимо вместе с ней получить данные о конфигурации, что довольно затруднительно. Поэтому остается только искать дропер, то есть ждать, пока малварь не влипнет в HoneyPot, принадлежащий реверсеру или одному из его партнеров.

WWW

Тема сокрытия трафика подробно изложена Жанной Рутковской, так что не будем повторять уже сказанное, а просто откроем ее блог и почитаем: theinvisiblethings.blogspot.com.

Категория: Общие Статьи | Добавил: aka_kludge (02.09.2009) | Автор: Крис Касперски
Просмотров: 1532 | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
    Главная      
...
На службе : дней

07:09
Обновить


Пользователи
aka_kludge
qwerty
LeadyTOR
aka_Atlantis
AdHErENt
mAss
Sissutr
hiss
DrBio
tHick

Поиск


Copyright tHR - TeAM 2024 г. admin: aka_kludge (ICQ:334449009) Moderator's: LeadyTOR, ... Яндекс.Метрика