Службы Windows всегда были излюбленной мишенью вредоносных программ и взломщиков. Это связано с тем, что, во-первых, многие службы Windows активны по умолчанию и могут устанавливать соединения с сетью, а, во-вторых, многие службы выполняются в привилегированном контексте безопасности, например локальной системной учетной записи. Если такая служба скомпрометирована, вредоносная программа может выполнять любые действия в системе, в том числе: устанавливать программы; просматривать, изменять и удалять данные; создавать новые учетные записи.
Червь Blaster — печально известный пример программы, которая нанесла ущерб ИТ-инфраструктурам во всем мире через службу Windows с высокими привилегиями. Blaster использовал службу удаленного вызова процедур (RPC) Windows, чтобы вызывать переполнение буфера и запускать на пораженных компьютерах программы с привилегиями локальной системной учетной записи.
В Windows Server 2008 и Windows Vista применяются изоляция сеанса 0, новые ограничения при использовании наименьших привилегий для служб, специфические для службы идентификаторы сеанса (SID), идентификаторы SID и маркеры с ограничением записи, а также ограничения доступа к сети, чтобы снизить риск атак на службы. Совместно эти изменения известны как ограниченный режим работы служб Windows.
Изоляция сеанса 0
Windows проектировалась как многопользовательская система, в которой пользователи могут работать с операционной системой параллельно. В частности, разрешается одновременный доступ пользователя к данным сервера файлов. Диспетчер сеанса Windows (smss.exe) — дирижер многопользовательской системы, который управляет сеансами терминалов (обычно именуемыми просто сеансами — не путать с сеансами регистрации пользователя в системе и на сервере терминалов) для пользователей. Диспетчер сеанса — один из первых процессов, запускаемых при загрузке Windows.
Сеансы обеспечивают некоторую степень изоляции между службами и приложениями, запускаемыми в различных сеансах. Не составляет труда организовать связь между процессами, выполняемыми в одном сеансе, но обмен данными между сеансами ограничен и подвергается определенным проверкам. Более подробную информацию о механизме диспетчера сеанса можно найти в книге Марка Русиновича и Дэвида А. Соломона «Microsoft Windows Internals».
Первый сеанс, созданный при загрузке операционной системы, именуется сеансом 0 или сеансом консоли. В версиях Windows, предшествующих Vista, в сеансе 0 выполняются службы и приложения, запускаемые первым пользователем, интерактивно зарегистрировавшимся в Windows. Однако запускать пользовательские приложения в сеансе 0 рискованно, так как в этом случае злоумышленник легко вмешается в функционирование привилегированных служб.
Благодаря изоляции сеанса 0 в Server 2008 и Vista только службы Windows могут выполняться в сеансе консоли. Приложения, запущенные первым пользователем, который прошел интерактивную регистрацию, находятся в другом сеансе с именем «сеанс 1». Поэтому они не могут воздействовать на службы с высокими привилегиями. На рисунке показаны различия между архитектурой управления сеансами Windows XP и Windows Server 2003, с одной стороны, и Windows Server и Vista — с другой.
В Server 2008 и Vista сеанс 0 также отмечен как неинтерактивный, то есть службы не могут напрямую связываться с пользователями (например, службы не могут выводить диалоговые окна, требующие ввода информации пользователем). В прошлом в ходе некоторых атак применялись возможности взаимодействия с пользователями интерактивных служб. Теперь службы, даже отмеченные как интерактивные или с установленным в свойствах службы параметром Allow service to interact with desktop, невидимы для пользователей. Службы будут функционировать, но пользователь в графической оболочке Windows их не увидит.
Последствия изоляции сеанса 0 и того обстоятельства, что этот сеанс отмечен как неинтерактивный, можно увидеть при использовании команды At (at.exe) в Server 2008 или Vista для планирования интерактивного выполнения программы. Планировщик заданий выполняется в сеансе 0 и поэтому не может выполнять программы, взаимодействующие с рабочим столом пользователя. Планировщик информирует пользователя об этом ограничении при планировании интерактивной программы, как показано на экране 1.
Сеанс 0 отмечен как интерактивный, но это не означает, что службы сеанса 0 не могут взаимодействовать с пользователями — такая функциональность некоторым приложениям необходима. Разработчики могут использовать инструменты безопасной связи между процессами, такие как именованные каналы и вызовы RPC, чтобы обеспечить безопасное взаимодействие служб сеанса 0 с рабочим столом. Дополнительные сведения о последствиях изоляции сеанса 0 и способах изолирования разрабатываемых приложений, служб и драйверов приведены в техническом документе Microsoft «Impact of Session 0 Isolation on Services and Drivers in Windows Vista» по адресу www.microsoft.com/whdc/system/vista/services.mspx.
Компания Microsoft позволяет обойти неинтерактивную природу сеанса 0 для старых служб или служб, в которые потребителям не удается быстро внести изменения. Это делается с помощью службы Interactive Services Detection (ui0detect.exe). По умолчанию данная служба отключена. Если ее активизировать (из узла Services в оснастке Active Directory Users and Computers консоли Microsoft Management Console (MMC) или из командной строки с помощью sc.exe), она дает возможность унаследованным интерактивным службам взаимодействовать с пользователем. Если служба пытается взаимодействовать с пользователем, ui0detect запрашивает у пользователя разрешение, прежде чем вывести на экран диалоговое окно службы.
Обходной маневр с применением службы Interactive Services Detection небезопасен (именно поэтому служба по умолчанию отключена) и является временной мерой. Вредоносные программы могут воспользоваться ею для взаимодействия с пользователем. Разработчики Microsoft планируют удалить службу ui0detect из следующей существенно обновленной версии Windows.
Кроме того, служба Interactive Services Detection работает только со службами на основе графических диалогов Windows, но не со службами на базе консоли или командной строки. Включение службы ui0detect не активирует повторно команду At для выполнения интерактивных задач.
Ограничения при предоставлении наименьших привилегий
Server 2008 и Vista располагают несколькими механизмами назначения наименьших привилегий, которые обеспечивают доступ службы только к привилегиям, необходимым для выполнения конкретной задачи — не больше и не меньше. Например, разработчики Microsoft заново пересмотрели разрешения и права, назначаемые по умолчанию встроенным службам Windows, и удалили несколько ненужных разрешений и прав. Кроме того, многие службы, выполняемые на локальном компьютере в прежних версиях Windows, могут функционировать как LocalService или NetworkService (менее привилегированные службы, появившиеся в XP SP2 и Windows 2003).
Также полностью обновлен механизм, который указывает и принудительно применяет права, назначенные службе. Он похож на контроль учетных записей (UAC) с наименьшими привилегиями для служб. Компонент наименьших привилегий Server 2008 и Vista, UAC, обеспечивает по умолчанию выполнение пользовательских приложений с малыми привилегиями, а все пользователи, в том числе администраторы, имеют только базовые привилегии пользовательского уровня. Основные сведения о UAC можно найти в статье «Использование минимальных привилегий в Windows Vista», опубликованной в Windows IT Pro/RE № 1 за 2007 г.
Механизм наименьших привилегий работает следующим образом. Компонент Service Control Manager (SCM) назначает привилегии службам в соответствии с информацией о привилегиях, указанной для службы в параметре реестра RequiredPrivileges. SCM действует так, что только привилегии, указанные в параметре RequiredPrivileges, активны в маркере доступа процесса, в котором размещается служба. SCM также применяет параметры RequiredPrivileges за пределами начального запуска системы. Таким образом, службе нельзя назначить дополнительные привилегии, пока она функционирует. Информация о настройках всех служб хранится в разделе реестра HKEY_LOCAL_MACHINESystemCurrent ControlSetServices, который содержит подразделы для каждой активной службы.
Предположим, создана служба с именем MyService и настроена на выполнение в контексте безопасности локальной системной учетной записи (то есть учетной записи службы MyService). В Server 2008 и Vista можно указать, что службе MyService требуется только право Backup files and directories. Для этого нужно внести данное право в параметр реестра RequiredPrivileges. Когда SCM запускает службу MyService, активизируется только право Backup files and directories в маркере доступа процесса, в котором размещается MyService. В ранних версиях Windows у хост-процесса был маркер доступа, активирующий все привилегии, назначенные локальной системной учетной записи по умолчанию. Возможности этой учетной записи в компьютере Windows чрезвычайно широки, поэтому данный подход обеспечивает службе большие привилегии.
Чтобы установить параметр реестра RequiredPrivileges и указать права, которые должна иметь служба, можно использовать команду SC. Для примера, можно ограничить права MyService, выполнив команду
sc privs MyService SeBackupPrivilege
Чтобы увидеть нужные права, как они указаны в параметре реестра RequiredPrivileges, используйте команду
sc qprivs service_name
где service_name — имя службы, права которой требуется увидеть. На экране 2 показаны необходимые права, как они указаны в реестре для службы удаленного управления (WinRM).
Увидеть результат фильтрации прав SCM можно с помощью инструмента Windows Sysinternals Process Explorer. Его можно получить по адресу technet.microsoft.com/en-us/sysinternals/bb896653.aspx. Запустите программу Process Explorer и щелкните на имени процесса правой кнопкой мыши, чтобы открыть его свойства, а затем перейдите на вкладку Security. На экране 3 показаны свойства безопасности процесса Winlogon, как они отображаются в Process Explorer. Обратите внимание, что, хотя Winlogon выполняется в контексте безопасности локальной системной учетной записи (NTAuthoritySystem), в его маркере доступа есть несколько отключенных прав, налагаемых новыми ограничениями в наименьших привилегиях.
Специфические для службы идентификаторы SID
В Server 2008 и Vista каждая служба может иметь специфический идентификатор SID. Администраторы и разработчики служб могут использовать специфический SID в списках управления доступом (ACL) для защиты ресурсов, относящихся к службе. В ранних версиях Windows при использовании встроенной учетной записи службы (например, локальная системная учетная запись, учетная запись сетевой службы) для запуска службы и предоставления учетной записи службы доступа к ресурсу пользователь неявно разрешал и всем другим службам, выполняемым с той же учетной записью, доступ к этому ресурсу, независимо от того, нуждались они в нем или нет. Чтобы избежать этой проблемы, администраторы обычно создают специальную учетную запись Windows для запуска отдельных служб. Но такой метод требует дополнительных усилий при управлении учетной записью. При создании специальной учетной записи нельзя задействовать автоматизированные функции управления паролем, предоставляемые операционной системой для встроенных учетных записей Windows.
В Server 2008 и Vista можно создать специфический для службы идентификатор SID, поэтому нет необходимости беспокоиться о процессе создания и обслуживания специальных учетных записей служб. Специфический SID связан с именем службы (например, MyService), а не учетной записью службы (например, LocalSystem) или специальной учетной записью Windows. Благодаря специфическим для службы SID можно по-прежнему использовать встроенные учетные записи служб для проверки подлинности службы, применяя специфический для службы SID, чтобы назначать разрешения для ресурсов службы.
Если нужно назначить специфический для службы идентификатор SID, необходимо установить свойство типа SID службы в значение unrestricted или restricted — различие между двумя типами свойств объясняется ниже в разделе о маркерах с ограниченной записью. Тип SID службы можно назначить с помощью команды SC:
sc sidtype service_name unrestricted
Чтобы запросить текущее значение типа SID службы, нужно ввести команду
sc qsidtype service_name
Если у службы есть специфический идентификатор SID, Windows автоматически вычисляет SID и связывает его со службой. При следующем запуске службы этот SID добавляется к маркеру доступа процесса, в котором размещается служба. Специфические для службы идентификаторы SID — локальные (на уровне компьютера, а не домена).
Специфический для службы SID строится на основе имени службы с использованием формата S-1–5-80-{SHA-1 (имя службы в верхнем регистре)}. Как можно заметить, SID для конкретной службы одинаков для всех компьютеров Vista и Server 2008, что заметно упрощает назначение разрешений для службы на разных компьютерах.
Назначенный для службы SID можно использовать для ограничения доступа к файловой системе и ресурсам реестра службы. Чтобы указать специфический для службы идентификатор SID при назначении разрешений для ресурса, используйте синтаксис: NT SERVICEservice_name.
Идентификаторы SID и маркеры с ограничением записи
Благодаря специфическим для службы идентификаторам SID администраторы могут более тщательно контролировать доступ к ресурсам службы. Однако специфический для службы SID не помешает службе обратиться к ресурсам, доступ к которым предоставляется по идентификатору SID учетной записи службы. Предположим, что MyService выполняется в контексте безопасности локальной учетной записи службы и для нее определен специфический для службы SID. Помимо доступа к объектам, который открывает этот SID, MyService может обращаться ко всем объектам, доступным для локальной учетной записи службы. Если злоумышленнику удастся скомпрометировать MyService, он сможет получить доступ к ресурсам, не относящимся к службе.
В Server 2008 и Vista проблема решается введением специфических для службы идентификаторов SID с ограничением записи (далее в статье именуемым ограниченными SID). Специфический для службы SID можно сделать ограниченным, установив свойство типа SID в значение restricted:
sc sidtype MyService restricted
Разработчики могут назначить идентификатору SID службы ограничение по записи, дополнив код службы флагом WRITE_RESTRICTED. Если у службы есть SID с ограничением записи, то при попытке доступа к ресурсу со стороны службы выполняется дополнительная проверка контроля доступа. Проверка контроля доступа состоит из двух независимых этапов. Доступ предоставляется лишь в том случае, если оба этапа пройдены успешно.
Первый этап представляет собой обычный контроль доступа, который выполняется всегда. На данном этапе Windows оценивает, следует ли предоставить службе доступ к ресурсу в соответствии с разрешениями ресурса и информацией в маркере доступа хост-процесса службы.
Второй этап предполагает дополнительный контроль доступа, обычно отсутствующий. На втором этапе Windows проверяет, предоставляют ли разрешения ресурса явный доступ по записи специфическому для службы SID или заранее определенным идентификаторам SID с типами Logon SID, Everyone или WRITE RESTRICTED.
Идентификаторы SID с ограничением можно использовать только для ограничения доступа к службе, но не расширения доступа. Например, если службе MyService назначен SID с ограничением, то MyService не может записывать данные ни в один из объектов, доступных для записи из LocalService, если только эти объекты явно не предоставили право записи идентификатору SID службы MyService.
Хотя идентификаторы SID с ограничением записи существенно повышают безопасность, для управления ими требуются дополнительные усилия. Для корректного функционирования службы, имеющей SID с ограничением записи, необходимо отыскать все ресурсы, в которые служба должна выполнять запись, а затем явно назначить разрешение записи для каждого.
Windows Firewall (mpssvc.exe) — пример службы, для идентификатора SID которой предусмотрено ограничение записи. Она размещается вместе с другими службами в единственном экземпляре процесса svchost.exe. Учетная запись службы экземпляра svchost.exe является локальной системной учетной записью. С помощью инструмента SysInternals Process Explorer можно проверить содержимое маркера доступа экземпляра svchost.exe. Откройте свойства экземпляра svchost.exe службы Windows Firewall и перейдите на вкладку Security. Пример интерфейса показан на экране 4.
Так как SID определен как ограниченный для записи, только службе Firewall (но никакой иной службе, выполняемой в контексте безопасности локальной системной учетной записи) разрешено записывать в ресурсы, для которых идентификатору SID службы Firewall предоставлен явный доступ для записи. Один из таких ресурсов — папка %System%LogFilesFirewall, в которой хранятся журналы Windows Firewall.
Ограниченный доступ к сети
Последний элемент ограниченного режима работы служб Windows состоит из ограничений, налагаемых разработчиками на доступ службы к сети. Широко распространенное заблуждение о новых ограничениях доступа служб к сети заключается в том, что они интегрированы с сетевыми ограничениями, определенными в Windows Firewall (персональный брандмауэр, функционирующий на каждой платформе Vista и Server 2008). В действительности это не так. Ограничения доступа к сети для службы:
-
проверяются прежде правил Windows Firewall;
-
применяются независимо от состояния Windows Firewall, даже если Windows Firewall отключен;
-
могут использоваться только для ограничения (запрета) доступа для службы, но не предоставления (разрешения) доступа;
-
могут использоваться как для входящих, так и для исходящих соединений со службами;
-
не могут быть заданы из оснастки Windows Firewall with Advanced Security консоли MMC или с помощью команды netsh advfirewall — они должны быть определены программно с использованием интерфейсов программирования INetFwServiceRestriction и INetFwRule.
Помимо предоставляемой разработчикам возможности определять особые ограничения доступа к сети, Server 2008 и Vista располагают набором готовых ограничений доступа к сети для встроенных служб. Заранее определенные ограничения нельзя изменить из упомянутых интерфейсов программирования, но пользователь с привилегиями административного уровня может изменить их в системном реестре. Оба типа ограничений доступа к сети хранятся в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrent
ControlSetServicesSharedAccessParametersFirewallPolicyRestrictedServices. Заранее определенные ограничения хранятся в разделе StaticSystem, как показано на экране 5; пользовательские ограничения хранятся в разделе Configurable.
Ограниченный режим работы служб Windows — важный шаг на пути к тому, чтобы сделать Windows фундаментально безопасной платформой. Вероятно, процедуру настройки мер безопасности можно было бы упростить, но не исключено, что разработчики намеренно отказались от упрощений: укрепление защиты служб — задача, которую следует оставить разработчикам и специалистам по безопасности. Тем не менее каждый администратор Windows должен хорошо понимать принципы ограниченного режима работы служб Windows.
Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft
Планировщик задач предупреждает о невозможности исполнения программы по расписанию
Просмотр заранее определенных ограничений доступа службы к сети в реестре