Книга "Недокументированные возможности Windows XP. Библиотека пользователя", Глава 4. Другие возможности Windows XP. Часть 3. Рассуждения о безопасности.

Как говорилось раньше, использование группы ОПЫТНЫЕ ПОЛЬЗОВАТЕЛИ не приветствуется Microsoft, так как данная группа имеет очень многие права в системе. В данной главе хотелось бы рассказать еще об одной причине, по которой лучше не использовать группу ОПЫТНЫЕ ПОЛЬЗОВАТЕЛИ — о способе получения прав администратора или отдельной его учетной записи в том случае, если на взламываемой машине у вас есть учетная запись опытного пользователя. Либо любая другая учетная запись, имеющая права на запуск служб, например, этим способом может воспользоваться администратор, которому вы запретили создавать других администраторов, чтобы обойти ваше ограничение. Также для работы данного метода на взламываемой системе должны быть установлены дополнительные сервисы, о которых будет рассказано в следующем абзаце.

Для реализации данного метода взлома необходима сторонняя служба, файл которой в Windows не защищается WFP, а также к которой вы имеете доступ. Еще одним требованием к службе является обязательное разрешение взаимодействия с рабочим столом, а значит, служба должна запускаться от имени системы. Как правило, такие службы появляются при установке антивирусов (например, антивируса Касперского), различных пакетов для программирования (например, Microsoft Visual C++ или Microsoft Visual Studio .NET), программ получения сведений о системе (например, SySoftware Sandra), программ эмуляторов операционной системы (например, VMware) и других программ, которые требуют для своих нужд права администратора.

Рисунок 1 Рис. 4.04. Вот пример службы, файл которой не защищен WFP, так как он не находится в каталоге %systemroot%\system32

Если все условия выполняются, а, как правило, они выполняются уже потому, что сейчас офис или отдельный компьютер невозможен без установки антивируса, не говоря уже о других программах, тогда можно начать попытку взлома. Для этого нужно скопировать файл explorer.exe, расположенный в каталоге %systemroot%, в каталог, который используется для хранения файла службы, например, как показано на рисунке 4.04, в каталог %programfiles%\common files\microsoft shared\VS7Debug. После этого необходимо переместить куда-нибудь файл службы (на рисунке 4.04 это файл mdm.exe), а файлу explorer.exe присвоить имя перенесенного нами файла службы (в нашем случае, mdm.exe).

Вот и все приготовления, которые могут занять у вас несколько минут. Дальше есть две линии сюжета: если служба на данный момент не запущена, тогда просто запускаем ее и переходим к следующему абзацу книги. Если же служба в данный момент работает, тогда нужно выполнить перезагрузку компьютера (обязательно перезагрузку, если вы просто смените сеанс, то ничего не произойдет — служба не будет перезапущена). После перезагрузки компьютера, еще до загрузки оболочки, но уже после ввода регистрационных данных пользователя, перед вами отобразится окно проводника. Это говорит о том, что запустилась наша измененная служба (конечно, это произойдет только в том случае, если параметр TYPE для службы равен 110, а параметр START для службы равен 2, что говорит о том, что наша служба является приложением и запускается при входе пользователя в систему сервисом smss.exe). На данный момент данное окно проводника нам не нужно, поэту просто закрываем его. Теперь в диспетчере задач (нажмите комбинацию клавиш CTRL+ALT+DEL для получения окна диспетчера задач) нужно самому запустить оболочку explorer.exe, так как ваша оболочка теперь самостоятельно не загрузится. Для этого в меню ФАЙЛ выбираем пункт НОВАЯ ЗАДАЧА (ВЫПОЛНИТЬ…) и в появившемся диалоговом окне вводим команду explorer.exe. Все, теперь вы полностью вошли в систему и при этом измененная нами сторонняя служба не запущена (все приведенные действия мы делали потому, что опытные пользователи могут запускать службы, но не останавливать их). Осталось только одно — запустить оснастку services.msc и самостоятельно запустить измененную нами службу.

После запуска службы перед вами появится окно проводника, в адресной строке которого нужно быстро ввести команду %systemroot%\system32\lusrmgr.msc (лучше просто поместить команду в буфер обмена перед выполнением данного шага взлома).

Естественно, что вы можете ввести и другие команды, например, команду %systemroot%\system32\cmd.exe, чтобы открыть окно командного процессора с правами системы (или учетной записи, от имени которой запускалась сторонняя служба).

Вы спросите, почему нужно вводить быстро? Все дело в том, что файл проводника, которым мы заменили файл службы, не предназначен для запуска как служба. А это значит, что он не ответит на запросы оснастки services.msc (хотя, как видите, это не мешает системе запустить файл оболочки). А если служба не отвечает на запросы, тогда через некоторое время система автоматически завершит такую службу.

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

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

Рисунок 2 Рис. 4.05. Система завершила не отвечающую службу, но не завершила другие процессы, порожденные ей, поэтому у нас теперь есть оснастка с правами системы

Как можно заметить из приведенного выше способа взлома, стандартной системной учетной записью можно воспользоваться для получения прав администратора. Это происходит потому, что эта запись имеет в чем-то даже больше прав, чем учетная запись администратора и, как правило, администраторы компьютера не ограничивают учетную запись системы (а в основном, просто не замечают угрозы этой записи). При рассмотрении групповых политик мы также узнали, что настройки интерфейса Internet Explorer также записываются в ветвь реестра от имени учетной записи системы (от имени процесса winlogon). Это также довольно сложно понять. Если групповые политики может редактировать только администратор, тогда почему необходимо использовать процесс winlogon? Здесь также, кстати, скрывается возможность взлома — получение прав администратора или изменение любых элементов реестра и файловой системы компьютера с помощью процесса winlogon, запущенного от имени системы. Все дело в возможности импортирования настроек конфигурации браузера, программ на вкладке ПРОГРАММЫ или настроек ограничений в inf-файлы каталога %systemroot%\system32\GroupPolicy\User\Microsoft\IEAK\BRANDING с помощью элемента групповой политики НАСТРОЙКА INTERNET EXPLORER. Ведь если добавить в данные inf-файлы свои действия, например, редактирование ветвей реестра или добавление/удаление объектов файловой системы, тогда при следующем доступе к политике НАСТРОЙКА INTERNET EXPLORER все добавленные вами строки будут выполнены от имени системы.

Единственное, что по умолчанию делает невозможным выполнение данного метода взлома, является запрет на работу с консолью ГРУППОВАЯ ПОЛИТИКА, а также редактирование импортируемых inf-файлов для пользователей с учетными записями, отличными от группы АДМИНИСТРАТОРЫ. Именно поэтому категорически запрещено изменять настройки доступа к каталогу %systemroot%\system32\GroupPolicy\User и его содержимому. Хотя и это только вершина айсберга, ведь мы не знаем, как процесс winlogon создает inf-файлы. Может быть, можно подобрать такое значение параметра реестра (который он записывает в inf-файл), которое будет вызывать неправильную запись в inf-файл значения параметра реестра? Например, чтобы на основе значения параметра реестра в inf-файле создавалось не только значение этого параметра, но и новая строка inf-файла, выполняющая произвольный код? Например, после некоторых экспериментов получилось создать в inf-файле «мусор», то есть, произвольный текст после значения параметра, который не обрабатывается. А можно ли как-нибудь записать в одну строчку inf-файла две команды? Или указать в значении параметра реестра какой-либо специальный символ (ведь реестр поддерживает Unicode), который при обработке процессом winlogon или inf-файлом будет интерпретироваться как переход на другую строчку? Надеюсь, программисты Microsoft могут с уверенностью ответить отрицательно на все эти вопросы, иначе перед нами очередной потенциальный способ выполнения любых операций с реестром и файловой системой Windows XP от имени системы. Причем, этим способом смогут воспользоваться не только представители группы ОПЫТНЫЕ ПОЛЬЗОВАТЕЛИ, но и группы ПОЛЬЗОВАТЕЛИ.

Другим интересным вопросом является озвучивание системных событий. Как оказывается, озвучивание события также выполняется процессом winlogon. При этом путь к музыкальному файлу для озвучивания события хранится в ветви реестра, доступной для редактирования любым пользователям. Здесь также возникают вопросы. А нельзя ли вместо озвучивания музыкального файла выполнить какой-нибудь произвольный код? Или вместе с музыкальным файлом? Или, например, указать путь к ярлыку на музыкальный файл, а этот ярлык, в свою очередь, будет ссылать на музыкальный файл, доступ к которому вам, как пользователю, был запрещен. Да здесь, собственно, и ярлык не нужен, как оказывается, так можно прослушать даже тот файл, доступ к которому вам был полностью запрещен, но вы точно знаете, где этот файл находится. Как это сделать? Все музыкальные файлы для озвучивания событий описаны в ветви реестра HKEY_CURRENT_USER\APPEVENTS\SCHEMES\APPS. Например, параметр по умолчанию ветви реестра HKEY_CURRENT_USER\APPEVENTS\SCHEMES\APPS\.DEFAULT\SYSTEMHAND\.CURRENT определяет путь к файлу, который будет проигрываться процессом winlogon при возникновении критической ошибки. То есть, вы можете указать здесь путь к любому музыкальному файлу, а потом, например, просто ввести в диалоге ЗАПУСК ПРОГРАММЫ любую строку, не ассоциированную с программой, например, введите символ b. Скорее всего, система не найдет программы с названием b.exe, а значит, произойдет событие критической ошибки и будет воспроизведен необходимый вам файл.

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

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

Также интересна сама необходимость учетной записи системы с полными правами. Например, зачем службам такие возможности, как изменение ACL объектов или создание учетных записей администраторов? Зачем той же winlogon такие возможности. Намного безопасней будет создать несколько ограниченных учетных записей системы, которые могут выполнять только определенные задачи, которые могут понадобиться той или иной службе.

Продолжение следует