Хроника внедрений в автозагрузку

Скрытые ключи автозапуска в системном реестре

Существует множество широко известных ключей автозапуска, в которые прописываются вирусы, черви, трояны и другие программы, пытающиеся внедриться в атакуемую систему, и которые проверяют антивирусы, брандмауэры и прочие сторожевые механизмы, бьющие хакеров еще на старте. Чтобы выжить в этом суровом мире, полном ужасных защитных монстров, приходится извращаться не по-детски и разрабатывать методики поиска малоизвестных ключей автозапуска, неподвластные никаким анализаторам реестра.

Для поддержания своей жизнедеятельности малварь должна хотя бы изредка получать управление. В идеале — при каждой загрузке операционной системы, что достигается, например, через прописывание пути к исполняемому файлу в следующей ветви системного реестра: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Однако это очень плохой способ, поскольку появление нового элемента в разделе \Run редко остается незамеченным. О нем знают как защитные механизмы (антивирусы, персональные брандмауэры, разные диагностические утилиты), так и продвинутые пользователи.

Хакеры и разработчики антивирусов ведут непрекращающиеся археологические раскопки реестра, ковыряя его с двух сторон, причем каждая сторона стремится найти как можно больше ключей, прямо или косвенно связанных с автозапуском. Необязательно юзать общесистемные ключи, относящиеся непосредственно к Windows. Для решения поставленной задачи вполне достаточно прицепиться к часто запускаемому приложению, например к IE, стартуя вместе с его запуском.

Реестр содержит тысячи (если не сотни тысяч!) подходящих ключей, но только несколько десятков из них контролируются защитными механизмами. На хакерских форумах начинающие кодокопатели часто спрашивают полный список ключей автозапуска или перечень новых ключей, появившихся в XP, Висте или другой операционной системе. Их вопрос обычно остается без ответа (обвинения в ламеризме не в счет), а все существующие списки (которые, кстати говоря, можно запросто выковырять из любой антивирусной программы — они там, как правило, лежат открытым текстом) представляют интерес в основном для разработчиков защит. Использовать их для внедрения малвари — сплошное пионерство, и долго такая малварь не проживет.

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

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

План перехвата ассоциации расширений

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

Запустим редактор реестра и откроем раздел HKEY_CLASSES_ROOT, образованный (как известно) путем слияния данных из двух источников: HKLM\SOFTWARE\Classes и HKCU\SOFTWARE\Classes. Первый носит глобальный характер, распространяющийся на всех пользователей, зарегистрированных в системе, и требует для своей модификации права администратора (которых у малвари чаще всего нет). Второй относится только к текущему пользователю, прав администратора он не требует, но и не затрагивает всех остальных.

Отсюда правило: сначала мы пытаемся модифицировать HKLM\SOFTWARE\Classes и, если обламываемся, либо повышаем свои привилегии до уровня администратора (используя тот или иной хак), либо переключаемся на HKCU\SOFTWARE\Classes, будучи готовыми к тому, что прав на его модификацию у нас может и не быть (однако в живой природе такие жестоко ущемленные пользователи практически не встречаются, значительная их часть постоянно сидит под администратором - а потом еще удивляются, откуда вирусы берутся в таких количествах!).

В [HKLM|HKCU]\SOFTWARE\Classes, помимо прочей полезной информации, хранится список зарегистрированных расширений и указания по их обработке при запуске файлов через стандартную оболочку типа проводника или команду start, набираемую в командной строке. Файловые менеджеры FAR и Total Commander также используют список зарегистрированных расширений путем вызова API-функций ShellExecute/ShellExecuteEx и/или команды start (поведение зависит от текущих настроек).

За этими ветвями практически никто не следит. «Практически» — потому что ассоциированные приложения могут проверять целостность ассоциаций при каждом запуске и ругаться матом, если их расширение оказалось сопоставлено с посторонним приложением. Также некоторые защитные системы могут контролировать ассоциации стандартных системных расширений типа exe, однако в общем случае перехват ассоциаций остается никем не замеченным, особенно если действовать по плану. А есть ли у нас план?! Конечно же есть!

Прежде всего необходимо выбрать расширение, которое мы собираемся атаковать. Это должно быть довольно распространенное расширение, открываемое пользователями по меньшей мере несколько раз в день, например txt или bmp. Нет, txt все-таки лучше. Вот и будем его терзать по полной программе.

Открываем HKEY_CLASSES_ROOT\.txt, смотрим на значение по умолчанию и видим, что там в данном случае находится ключ «txtfile», описывающий тип файла, а путь к сопоставленному с ним приложению хранится в HKEY_CLASSES_ROOT\txtfile\shell\open\command, где обозначена строка «%SystemRoot%\system32\NOTEPAD.EXE %1». Магическое число «%1» представляет собой первый аргумент командной строки, содержащий имя открываемого файла, ну а «%SystemRoot%\system32\NOTEPAD.EXE» — соответственно, всем известный блокнот.

Поставим перед собой задачу перехватить обработчик ассоциаций, запуская свой собственный исполняемый файл (необязательно вредоносный!) при открытии текстовых файлов так, чтобы факт перехвата остался незамеченным.

Самое простое, что только можно сделать, — это поменять «%SystemRoot%\system32\NOTEPAD.EXE %1» на «my_own_path\my_own_malware-file.exe %1», заставив систему вызывать my_own_malware-file.exe вместо блокнота. Естественно, блокнот при этом придется вызывать нам самим, не забыв передать ему первый аргумент командой строки (некоторые хакеры забывают, в результате чего блокнот открывает пустой файл, высаживая пользователя на измену).

Кстати говоря, это необязательно должен быть именно блокнот. Достаточно многие пользователи используют нестандартные редакторы, поэтому мы всегда должны считывать исходное содержимое \txtfile\shell\open\command, перемещая его куда-нибудь внутрь реестра или своего собственного ini-файла — туда, где его никто не найдет. Жестко прошивать вызов блокнота внутри my_own_malware-file.exe категорически недопустимо! Если у тебя текстовые файлы открываются блокнотом, это еще значит, что аналогичным образом обстоят дела и у других пользователей! Это грубейшая ошибка.

Остается устранить одну мелкую недоработку - и малварь готова к внедрению в промышленную эксплуатацию. Что это за недоработка? Сейчас увидим! Щелкаем по «Моему компьютеру» (ну, в смысле по твоему), в меню «Сервис» выбираем пункт «Свойства папки», в открывшемся диалоговом окне переходим ко вкладке «Типы файлов», находим среди расширений TXT, нажимаем кнопку «Дополнительно», в «Действиях» выбираем Open и... тайное сразу же становится явным! Система честно сообщает, что текстовые файлы она открывает с помощью my_own_malware-file.exe, что не может не вызывать у продвинутых пользователей серьезных подозрений, плавно переходящих в уверенность, что их поимели. Нет, нам это не подходит, и, чтобы малварь жила и процветала, нужно заныкать ее получше.

Идем на хитрость

Идея: берем NOTEPAD.EXE (или то имя, что ассоциировано с текстовыми файлами у пользователя) и заменяем одну латинскую букву на соответствующую ей русскую, аналогичную по начертанию, например, букву A, после чего переименовываем my_own_malware-file.exe в NOTEPAD.EXE (где А — русская) и осуществляем перехват по вышеописанной методике.

Даже если у пользователя установлена противная защитная программа, следящая за расширениями и ругающаяся при их изменении, жертва никак не отреагирует на предупреждение об опасности, посчитав, что это просто глюк. Посуди сам: «Внимание! Ассоциация расширения txt-файлов изменилась с NOTEPAD.EXE на NOTEPАD.EXE». Типа «масло масляное».

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

Естественно, на файлы, открываемые в FAR'е по <F4>, это никак не подействует, поэтому, если известно, что жертва активно пользуется FAR'ом, следует искать другой путь.

Хорошая идея — подменить стандартный обработчик exe-файлов, которые открываются пользователем намного чаще, чем все файлы документов, вместе взятые (на самом деле это плохая идея, поскольку за ассоциациями исполняемых файлов следят достаточно многие сторожевые программы, но… кто не рискует…).

Открываем HKEY_CLASSES_ROOT\.exe, видим, что значение по умолчанию установлено в exefile, лезем в HKEY_CLASSES_ROOT\exefile\shell\open\command, где находится «"%1" %*», что в переводе на русский язык означает запустить выбранный файл (имя которого передано в первом аргументе командной строки: «%1»), передав ему все аргументы, какие только есть: «%*». Если поменять «%1» на путь/имя нашего файла-перехватчика, то он будет запускаться всякий раз, когда пользователь щелкает по иконке исполняемого файла или нажимает на <Enter> в FAR'е. На некоторых хакерских форумах высказывается мнение, что такая замена носит рекурсивный характер, то есть файл-перехватчик отлавливает запуски всех исполняемых файлов, включая самого себя, в результате чего мы зацикливаемся в бесконечном рекурсивном спуске. На самом деле подобное утверждение совершенно безосновательно: система анализирует ассоциации только однажды, и потому рекурсии не возникает.

Исследуем реестр сами

Перехват ассоциаций — хоть и привлекательный, но все-таки не единственно возможный трюк, позволяющий малвари внедряться в систему. При желании можно пойти совсем иными путем, о котором не знает никто, кроме нас.

Как искать ключи, ответственные за автозагрузку? Да очень просто: запускаем редактор реестра, вбиваем в поиск «.exe» или «.dll» и ищем все ветки, откуда вызываются исполняемые файлы и динамические библиотеки. Вот, например, Adobe Acrobat содержит следующую замечательную ветвь HKLM\SOFTWARE\Adobe\Adobe Acrobat\PrintMe, в которой зарыто если не сокровище, то что-то на него похожее:

URL2KPMInst: https://www.printme.com/support/adobe/PrintMeDriverforWindows2000.exe

URL9XPMInst: https://www.printme.com/support/adobe/PrintMeDriverforWindows9x.exe

URLNTPMInst: https://www.printme.com/support/adobe/PrintMeDriverforWindowsNT.exe

URLXPPMInst: https://www.printme.com/support/adobe/PrintMeDriverforWindowsXP.exe

Не нужно иметь семь пядей во лбу, чтобы понять, что здесь лежат ссылки на динамически загружаемые драйверы для печати pdf-документов под разные системы. Так почему бы их не изменить?! Ну, драйверы печати — это еще туда-сюда (скорее всего, они уже установлены), но куча программ содержит URL'ы к серверам обновлений, которые проверяются при каждом запуске или через определенные промежутки времени.

Конечно, это не совсем автозагрузка, точнее, совсем не автозагрузка, но для внедрения малвари в систему она очень даже пригодна! В частности, панель Google хранит путь к файлу обновлений в ветке HKL\SOFTWARE\Google\Common\Google Updater\path: C:\Program Files\Google\Common\Google Updater\GoogleUpdaterService.exe, позволяя нам заменять GoogleUpdaterService.exe своей собственной программой, делающей все, что задумано, и передающей управление настоящей GoogleUpdaterService.exe. И никто ничего не заподозрит, более того, отыскать внедренную таким образом малварь практически нереально! Для этого необходимо знать назначение всех ключей реестра, а это невозможно, поскольку существует бесчисленное множество программ с никем не стандартизированными настройками.

Чисто теоретически можно периодически сканировать реестр на предмет изменений в ключах, содержащих «*.exe» и «*.dll», однако, во-первых, автору не известно ни одного готового сканера, который бы делал это, а во-вторых, даже если такой сканер и появится, он станет заложником большого количества ложных срабатываний. Например, стоит скопировать в FAR'е исполняемый файл из одной папки в другую, как его имя попадет в специальную ветку реестра, хранящую историю строки редактирования. Сканер, будучи тупой машиной, не может отсеивать ложные срабатывания, и для полноценного анализа нам понадобится человек, причем не просто человек, а весьма продвинутый пользователь, у которого малварь просто не водится.

Другая теоретическая возможность — запрет на модификацию всех потенциально опасных ветвей реестра. Что ж, операционные системы семейства NT имеют гибкую политику доступа, но… полный запрет на запись в реестр приведет к развалу системы. Следовательно, нужно тщательно проанализировать все ключи, отделить опасные от безопасных и… идти топиться! Ведь времени на это уйдет… Было бы просто замечательно, если бы разработчики программ думали головой и сразу сортировали свои настройки по степени потенциально опасности, устанавливая им надлежащие права доступа. Так ведь нет! Они ленятся и валят все в кучу! А пользователи потом страдают, находясь под угрозой атаки!

Впрочем, угроза атаки не так уж и велика. Несмотря на то что реестр содержит просто клад ветвей, пригодных для внедрения, их автоматизированный поиск невозможен, поскольку, как уже говорилось, тупая машина не в состоянии определить назначение ключей по их содержимому. Это может сделать только человек! Следовательно, места для внедрения необходимо искать еще на этапе написания малвари. Но тут мы сталкиваемся с тем, что многообразие используемых программ (и их версий) приводит к сужению круга потенциальных жертв. Впрочем, если брать широко распространенные программы (такие, например, как Adobe Acrobat Reader), то круг окажется не таким уж и узким.

Вместо заключения

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

Классы в ассоциациях

При перехвате зарегистрированных расширений необходимо быть готовым к встрече со странностями.

Странность первая (и легко преодолимая) - значение по умолчанию перехватываемого расширения содержит пустую строку вместо ожидаемого типа файла. Если это так, смотрим в подраздел ShellEx и ищем там длинную строку циферок (стандартный уникальный идентификатор). Например, в моем случае это HKEY_CLASSES_ROOT\.cdr\ShellEx\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}.

Смотрим, какое значение по умолчанию содержит ветка {BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}. Ага! Еще один идентификатор — {1AEB1360-5AFC-11d0-B806-00C04FD706EC}. Ищем его в реестре и… находим, черт возьми! Да ведь не возьмет! Ему такое добро ни даром, ни с доплатой не нужно.

Оказывается, что за таинственным идентификатором прятался OLE-компонент «Извлечение миниатюр графических фильтров Office», название которого содержится в параметре {1AEB1360-5AFC-11d0-B806-00C04FD706EC} ключа по умолчанию.

Спустившись на один уровень вглубь, мы откопаем ветку \InprocServer32, параметр по умолчанию которой задет путь к динамической библиотеке, используемой для отображения содержимого документов непосредственно в проводнике, причем не только cdr-файлов, но и многих других, отображаемых при помощи C:\WINNT\System32\thumbvw.dll.

Ситуация проясняется. У автора cdr-файлы не ассоциированы ни с каким приложением (именно потому значение по умолчанию содержит пустую строку), однако установленный пакет Microsoft Office позволяет просматривать их в виде миниатюр в проводнике.

Какие преимущества это нам дает? А вот какие: можно не только подменять существующие обработчики чужих файлов, но и устанавливать свои — тогда при выделении данного файла в проводнике система попытается отобразить его миниатюру, вызвав нашу динамическую библиотеку. Ассоциация типов при этом никак не изменится, и ни одна известная автору защитная программа не сможет отследить этот эквилибристический трюк.

Единственный минус такого решения в том, что он не работает, если пользователь предпочитает жить в FAR'е или в командной строке, однако большинство потенциальных жертв запускает файлы исключительно из проводника, и даже преданные поклонники командной строки прибегают к нему время от времени.

Странность вторая — значение по умолчанию пусто, как голова с бодуна, а подраздел \ShellEx отсутствует напрочь (ну или не содержит ничего интересного). Если так, открываем \PersistentHandler и в случае успешного завершения операции извлекаем его значение по умолчанию, которое может выглядеть, например, так: HKEY_CLASSES_ROOT\.dbg\PersistentHandler\{098f2470-bae0-11cd-b579-08002b30bfeb}.

Открываем HKEY_CLASSES_ROOT\CLSID\{098F2470-BAE0-11CD-B579-08002B30BFEB}\InprocServer32 и извлекаем оттуда имя динамической библиотеки или очередной идентификатор (если он там, конечно, есть) и поступаем с ним в соответствии с контекстом ситуации и нашей сексуальной ориентацией. Перехват динамических библиотек, реализующий OLE/COM/ActiveX, - довольно сложная задача, и начинающим лучше не браться за ее решение — глюков не оберешься! Лучше выбрать другой тип расширений для перехвата, благо недостатка в них испытывать не приходится.

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

WARNING

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

Крис Касперски