История о новой защите Sony, которая
оказалась настоящим руткитом, по моему
довольно интересна. Сегодня мы
представляем подробное описание работы
Марка Руссиновича, обнаружившего непрошеного
гостя в своем компьютере.
На прошлой неделе я тестировал последнюю
версию RootkitRevealer
(RKR) сканируя одну из моих систем. Довольно
неприятным сюрпризом для меня стало
обнаружение реального руткита... Обычно
руткиты тщательно скрывают свое
присутствие в системе, пряча файлы, ключи реестра
и другие объекты от постороннего взгляда и диагностики,
и потому руткит обычно скорее вредоносная
программа, нежели нормальный софт -
нормальной программе есть ли смысл
прятаться? Так или иначе, RKR обнаружил скрытую
директорию, спрятанный драйвер устройства,
приложение, файлы:
Появление руткита стало неприятным
сюрпризом для меня - я стараюсь не шастать в
Интернете где попало и уж тем более не
устанавливать программы из непроверенных
источников. Я просто терялся в догадках где
я мог подцепить руткит, и если бы не
подозрительное название фалов я бы скорее
сказал, что RKR ошибся в своей работе. Я
срочно запустил Process Explorer и Autoruns дабы
посмотреть что же активирует запуск
руткита, однако обе программы мне ничего не
показали. Настала очередь LiveKd,
утилиты для работы внутри живой Windows на
уровне дебагерра ядра, с ее помощью я
попытался определить компонент, отвечающий
за сокрытие руткита.
Руткит, скрывающий свои файлы, директории
и ключи реестра, может работать в user mode за
счет изменения Windows API, которые используются
для просмотра этих объектов, либо в kernel mode
за счет перехвата необходимых "ядерных"
API. В последнем случае стандартная практика
перехвата kernel-mode application API - изменение
таблицы системных вызовов, техника впервые
представленная в 1996 году с первой версией Regmon.
Каждый сервис в ядре, который используется
приложениями Windows, имеет указатель в
таблице который индексируется внутренней
службой и используется в системе. Если
драйвер заменяет любую запись в таблице
указателем на свою функцию, тогда ядро
обращается к драйверу каждый раз когда
приложению требуется API и таким образом
драйвер может контролировать работу
интерфейса (собственно, Хакер не раз писал о
разных техниках работы с таблицей, поэтому
отсылаю вас к поиску).
Довольно легко заметить перехват
системных вызовов просто загрузив
содержание таблицы: все функции должны
ссылаться на адреса, лежащие внутри ядра
Windows, все непропатченные функции. Livekd
показал мне адреса некоторых измененных
функций:
Я просмотрел одну из перехваченных
функций и увидел, что она является частью
драйвера Aries.sys, который как раз и находился
в скрытой директории $sys$filesystem. Вооруженный
знание того, что же осуществляет скрытие
руткита, я подумал что смогу убрать
невидимость и посмотреть на процессы, файлы,
директории, записи реестра наконец.
Несмотря на то, что RKR показал закрытость
\Windows\System32\$sys$filesystem от Windows API, обычная
практика для такой ситуации - возможность
открыть директорию ручками. Я захотел
проверить можно ли увидеть директорию из
командной строки . Оказалось, что вполне
возможно увидеть все ее содержимое:
Возможно переименование драйвера и
перезагрузка уберет невидимость, но я хотел
посмотреть что же еще делает Aries.sys. Я
скопировал программу в другую директорию и
проверил ее в дизассемблере IDA Pro. Ниже
скриншот кода, который подсчитывает записи
в таблице вызовов для дальнейшей
манипуляции:
Я изучил процедуру инициализации и увидел,
что она патчит несколько функций в
таблице системных вызовов и обнаружил, что
драйвер скрывает любые файлы, диры,
процессы и т.д., начинающиеся на $sys$. Для проверки
сделал копию Notepad.exe и назвал ее $sys$notepad.exe -
блокнот тут же исчез из поля зрения. Вне
функций скрытия драйвер оказался довольно
непрофессиональной программой. Дело в том,
что всегда небезопасно выгружать драйвер,
который патчит таблицу вызовов из-за того,
что некоторые потоки могут выполнять
первую функцию перехваченной функции во
время выгрузки драйвера, если это
происходит поток переходит на неправильный
адрес и вся система вешается. Для драйвера
нет возможности защитится от этой ситуации,
однако Aries поддерживает выгрузку и пытается
отслеживать любые потоки, исполняющие код.
В данном случае программист не учел такой
ситуации. Так или иначе программистам
придется искать новые пути работы руткитов,
так как перехват вызовов не всегда работает
на 64-битный версиях Windows.
После того, как я закончил изучение
драйвера я перезагрузил систему.
Невидимость руткита исчезла и я мог видеть
прежде недоступные файлы в Проводнике и
записи реестра в Regedit. Я сомневался, что
файлы имели информацию о версиях и
создателях, но все равно запустил Sigcheck для
их проверки. К моему удивлению, большинство
файлов удалось опознать. Dbghelp.dll и Unicows.dll
принадлежали Microsoft, остальные оказались частью
Essential System Tools, продукта компании First 4 Internet:
Недолгий поиск вывел меня на сайт http://www.first4internet.com/,
однако дальнейший поиск по программе или
Aries.sys ничего не дал. Сам факт, что компания
продает систему защиты контента под
названием XCP навел меня на подозрения, что я
стал жертвой именно такой системы. Поиск в
Gooogle вывел на другую
статью, рассказывающую о сделке со
звукозаписывающими компаниями, в частности
Sony, по внедрению Digital Rights Management (DRM) системы
для звуковых CD.
Ссылка на DRM заставила меня вспомнить о
недавно приобретенных компактах: они могли
проигрываться только плеером,
поставляющимся на самом диске. Недолгий
поиск по компактам вывел меня диск Sony BMG Get Right with the Man
от братьев Van Zant. При покупке никаких
сведения о DRM защите я не заметил, однако
более тщательное изучение сайта Amazon
действительно рассказало мне о том, что
этот диск поставляется с защитой.
Следующая фаза моего расследования:
убедиться что именно этот диск во всем
виноват. Я вставил диск и запустил плеер,
который кроме всего прочего позволяет
создать только три копии диска на диске. Process Explorer
показал, что плеер работает на основе
технология Мacromedia, но так же он показал
использование процессора прежде скрытым
процессом $sys$DRMServer.exe. Взгляд на свойства
процесса показал его название - Plug and Play Device Manager,
что явно является попыткой ввести обычного
пользователя в заблуждение с целью
заставить его думать, что это обычная часть
Windows:
Я закрыл плеер и понадеялся, что
использование CPU процессом прекратится,
однако $sys$DRMServer по прежнему потреблял от 1 до
2 процентов его времени...
(Продолжение следует)
|
