О потайных ходах и руткитах
Руткиты, как известно, служат для того, чтобы злоумышленник, взломавший систему и получивший привилегии суперпользователя, мог и в дальнейшем осуществлять к ней скрытный, несанкционированный, суперпользовательский доступ. То есть, руткит — это и потайной ход, и средство маскировки злоумышленной активности.
Руткиты являются разновидностью троянских программ и подразделяются на бинарные и руткиты уровня ядра. Первые подменяют системные утилиты, вторые — функции ядра, реализующие системные вызовы. Методологию классификации руткитов и детальные сведения о механизмах их функционирования можно найти, например, в статье .
Для выявления бинарных руткитов достаточно средств контроля целостности (таких, например, как Tripwire) ключевых системных файлов.
С руткитами уровня ядра ситуация существенно сложнее. Сигнатурный подход, разумеется, неэффективен и в этом случае. Если, например, изменен адрес таблицы системных вызовов в обработчике соответствующего прерывания, то какую сигнатуру и где следует искать? Дополнительную техническую проблему при реализации сканирования и проверки целостности файлов составляет отсутствие доверия к результатам системных сервисов.
Если руткит реализован с помощью механизма загружаемых модулей ядра (а это самый распространенный метод применительно к Linux-системам), можно попытаться, как рекомендуют авторы работы , перед загрузкой проводить бинарный статический анализ модулей с элементами символьного выполнения на предмет выявления признаков вредоносного поведения, таких как запись в управляющие структуры ядра. Но, по сути, это обобщенный антивирусный подход, сочетающий поиск сигнатур и эвристики, а его ограниченность известна. Правда, руткиты необходимо выявлять не среди произвольных программ, а среди модулей, тяготеющих к определенной внутренней структуре, характерной, например, для драйверов устройств, но методы обфускации программ и здесь оказываются достаточными для сокрытия признаков вредоносности. Точнее, можно прогнозировать "гонку вооружений" между средствами выявления признаков вредоносного поведения и их сокрытия.
Согласно опубликованным в статье результатам, предложенные и реализованные ее авторами методы позволили выявить все проверявшиеся руткиты (их было восемь) и не дали ни одного ложного срабатывания на почти пятистах легальных модулях. Время анализа, как правило, не превышало 10 мс, максимум составлял 420 мс (Pentium IV, 2 ГГц, 1 ГБ ОЗУ). Так что, несмотря на теоретические проблемы, наличие и серьезность которых авторы, разумеется, осознают, первые практические результаты оказались обнадеживающими, хотя пока не решались технические проблемы интеграции с ядром и обеспечения невозможности обхода контролирующего загрузчика модулей.
Загружаемые модули — серьезная угроза безопасности монолитных операционных систем, поскольку они имеют неограниченный доступ к коду и структурам данных ядра. На долю подобных модулей приходится до 70% кода ядра и от 70% до 90% ошибок, среднее время жизни которых составляет около 20 месяцев (см. ). Даже если отвлечься от злоумышленных руткитов, остаются угрозы, существующие благодаря уязвимостям в поспешно написанных драйверах устройств. Желательно каким-то образом организовать разграничение доступа в ядре, чтобы не допустить эксплуатации уязвимостей.
Работа развивает направление, намеченное в статье . Она предусматривает спецификацию допустимого и недопустимого поведения ("белые" и "черные" списки — адреса, по которым можно или нельзя выполнять переходы, данные, к которым разрешается или запрещается обращаться, области, где нельзя выполнять машинные инструкции, и т.п.). Частично выполнение спецификаций можно проверить статически, остальное контролируется динамически, за счет вставки проверочного кода. Утверждается, что накладные расходы при этом не превышают 23%. Отметим, однако, что будущее не за такими, явно временными, решениями, а за модульными операционными системами, полноценными моделями безопасности для их компонентов и аппаратной поддержкой при проведении политики безопасности в жизнь.
Руткиты можно считать одной из разновидностей скрытного программного обеспечения, включающего, например, средства протоколирования пользовательских сеансов.
Скрываться может как исполняемый код, так и используемые им ресурсы и ассоциированная информация. Например, вредоносный код можно поместить во флэш-память видеокарты, а для выполнения "впрыснуть" в существующий процесс. Ресурсы, такие как файлы и процессы, можно скрыть от пользователя, перехватывая системные вызовы по технологии руткитов. Пробовать выявить скрытное ПО можно по крайней мере двумя способами:
- пытаться обнаружить скрывающие механизмы (рассмотренные выше подходы — из этой категории);
- пытаться получить информацию о системе несколькими способами и отыскать различия в выдаваемых результатах (например, сравнить выдачи команд ls и echo * или информацию от ps и из таблицы процессов в ядре, естественно, предварительно приведя результаты к единому формату).
Раз скрытными ресурсами манипулируют, то можно надеяться, что в каком-нибудь (низкоуровневом) представлении они видны. В этом состоит основная идея подхода, предлагаемого в работе . Может показаться, что искать симптомы вместо первопричины болезни — неправильно, но если симптомы выявить проще, то почему бы этого не сделать? "Сканеры сравнения" можно регулярно запускать на всех компьютерах корпоративной сети, на сканирование одного гигабайта дискового пространства, согласно приведенным в данным, уходит порядка полуминуты, так что подобный подход представляется вполне практичным.
(Напомним, что в статье рассматривается применение "дифференциального" метода для выявления потайных каналов.)
Разумеется, желательно не только не допускать установки руткитов или оперативно выявлять таковые, но и проводить самолечение скомпрометированных систем. Последнее — тема статьи . Идея состоит в том, чтобы отслеживать изменения в таблице системных вызовов, появление скрытых файлов, процессов и сетевых взаимодействий, а по выявлении вредоносной активности — ликвидировать ее, восстанавливая корректное состояние таблицы системных вызовов, удаляя скрытые файлы, терминируя скрытые процессы, блокируя скрытые сетевые соединения.
По иронии судьбы, прототип данного защитного средства реализован в виде загружаемого модуля ядра и, следовательно, сам может стать объектом атак руткитов, не говоря уже о проблеме полноты диагностики и лечения систем.
Вопрос о том, кто будет охранять охранников, принадлежит к числу вечных и трудноразрешимых. Если защищаемая и защищающая системы совпадают, нет никаких гарантий, что после компрометации защитные средства будут работать корректно, а осуществляемое ими лечение окажется эффективным и полным. Одним из способов изоляции средств защиты является упоминавшаяся выше технология виртуальных машин. Ее применение в контексте выявления подозрительной активности рассмотрено в работе . К сожалению, в сетевой среде эта технология оказывается, с одной стороны, недостаточной, а с другой — накладной (и авторы работы , разумеется, осознают серьезность отмеченных проблем). Недостаточность состоит в том, что, несмотря на виртуализацию, система остается одним узлом сети, подверженным атакам на доступность и удаленной эксплуатации уязвимостей сетевых сервисов. Неэффективность объясняется необходимостью частых переключений между контекстами виртуальных машин и контролирующим их монитором.
(Заметим в скобках, что технология виртуальных машин — замечательное средство эффективной, экономически оправданной реализации приманок и ловушек, исчисляемых десятками тысяч, на нескольких аппаратных серверах, см. .)
(Также в скобках как курьез упомянем предложение авторов работы учиться методам обфускации у разработчиков руткитов, однако в этой статье есть прекрасная обзорная врезка с изложением основных фактов и положений, относящихся к руткитам.)
Только аппаратная поддержка сулит прорыв в информационной безопасности, реализацию систем, устойчивых к атакам, способных оперативно, автоматически самовосстанавливаться. К сожалению, системы, подобные той, что описана в работе , — дело будущего, причем не очень близкого.
