| Новые программы oszone.net |  |
При использовании учетных записей безопасности SharePoint существует большой риск создания слабых конфигураций системы, могущих открыть злоумышленникам всю среду SharePoint. Чтобы помочь пользователям правильно развертывать и защищать фермы серверов SharePoint, корпорация Майкрософт опубликовала большие объемы информации и подробные руководства. Руководство по безопасности Office SharePoint Server, например, состоит из более чем 300 страниц, посвященных планированию и реализации иерархий веб-узлов и содержимого, методов проверки подлинности, ролей безопасности, учетных записей администратора и служб и многих других вопросов безопасности. Таблица требований учетных записей безопасности Windows SharePoint также содержит ключевую информацию о конфигурациях учетных записей безопасности. Тем, для кого важна безопасность, определенно стоит следовать этой таблице. Даже при наличии подробной документации настройка учетных записей безопасности может быть сложной задачей. В действительности параметры по умолчанию односерверных установок отличаются от рекомендаций таблицы, а определенные компоненты, такие как веб-служба интеграции электронной почты, входящая в Windows SharePoint Services (WSS) 3.0, требуют повышенных прав на сервере, что не только не соответствует рекомендациям корпорации Майкрософт по безопасности, но и прямо противоречит практическому опыту безопасности и обычному здравому смыслу. Средство центрального администрирования SharePoint 3.0 Central Administration запросто производит ключевые настройки учетной записи без предупреждения, анализатор Microsoft Baseline Security Analyzer (MBSA) не обнаруживает возникающие слабости, так что обезопасить ферму серверов SharePoint и поддержать ее в таком состоянии по-прежнему непросто. В этой статье я рассматриваю учетные записи безопасности SharePoint под микроскопом, чтобы показать, как слабая конфигурация может дать взломщику полный контроль над всеми веб-узлами и их коллекциями. Это несколько щекотливая тема. С одной стороны, я хочу помочь читателям распознавать проблемы безопасности, связанные с настройкой серверов SharePoint. В конце концов, для эффективной защиты среды SharePoint необходимо понимать ее силы и слабости. С другой стороны, я не хочу помогать злоумышленникам. По этой причине я не прилагаю к этой статье никаких таблиц или собственных средств, а ограничу рассказ об исходном коде базовыми темами, которые должны быть знакомы любому профессиональному разработчику ASP.NET. Охваченные этой статьей фрагменты исходного кода должны помочь в обнаружении уязвимостей, но не в том, чтобы ими пользоваться. Даже в случае ограниченных программистских умений этими фрагментами можно воспользоваться, чтобы создавать собственные страницы ASP.NET, если есть Microsoft Office SharePoint Designer 2007. Пробная версия Microsoft Office SharePoint Designer 2007 доступна в сети. Я предлагаю читателям настроить лабораторию тестирования соответственно собственным предпочтениям, обезопасить ее настолько хорошо, насколько можно, и затем выполнить фрагменты кода в целях проверки. Посмотрим, насколько безопасны их веб-узлы SharePoint! Пулы приложений и учетные записи безопасностиУчетные записи безопасности лежат в самой основе модели обработки запросов SharePoint. Они определяют контекст безопасности рабочих процессов IIS, выполняющих веб-приложения SharePoint Web. При создании веб-приложения SharePoint необходимо указать, среди прочего, пул приложений со связанными с ним учетными данными записи безопасности и базу данных SharePoint, со связанным с ней методом проверки подлинности. При использовании проверки Windows (что рекомендуется) SharePoint автоматически дает указанной учетной записи базы данных разрешения dbOwner на базе данных содержимого, так что рабочий процесс IIS, выполняющий веб-приложение SharePoint, может получить доступ к веб-узлам и их коллекциям, размещенным в этой базе данных. В ином случае необходимо предоставить прямые учетные данные SQL Server. В любом случае, веб-узлы и коллекции веб-узлов SharePoint являются виртуальными конструкциями. Физически они соответствуют записям в базе данных. Если известны имя учетной записи и пароль, для установки прямого подключения SQL Server к базе данных содержимого можно получить полный доступ ко всем ее данным веб-узлов и их коллекций, вне зависимости от разрешений и элементов управления доступом, определенных на уровне SharePoint. SharePoint не может заблокировать пользователя, поскольку тот устанавливает прямое подключение к серверу базы данных, как показано на рис. 1. Учетная запись безопасности, таким образом, является основной целью для атаки.
Рис. 1 Обход веб-узлов SharePoint и их коллекций для получения доступа к данным Для смягчения угроз безопасности корпорация Майкрософт рекомендует настройку отдельных пулов приложений (и учетных записей приложений) для коллекций веб-узлов с проверенными и анонимными учетными записями и для изоляции приложений, сохраняющих пароли или тех, в которых пользователи могут свободно создавать и администрировать веб-узлы и сотрудничать по содержимому. Основная идея следования этой рекомендации состоит в том, что злоумышленник, получивший контроль над одним пулом приложений, не получит по умолчанию доступа ко всем данным, размещенным на ферме SharePoint. Веб-узлы SharePoint и их коллекции в других базах данных останутся за пределами его досягаемости, при условии использования отдельных учетных записей безопасности для связанных с ними веб-приложений. Корпорация Майкрософт впервые представила концепцию изоляции рабочего процесса, основанной на пулах приложений в IIS 6.0, и заявляет, что IIS ни разу с тех пор не пострадал от серьезной уязвимости в системе безопасности. Это весьма обнадеживает, так что не забудьте воспользоваться пулами приложений в фермах SharePoint. Но держите в уме, что веб-узлы IIS – это не синоним веб-приложений SharePoint. Хотя и возможна изоляция веб-узлов IIS, изолировать веб-приложения SharePoint друг от друга нельзя. Реальная изоляция существует только если у веб-узлов нет общих ресурсов, однако у веб-приложений SharePoint такие ресурсы есть всегда, скажем, база данных конфигурации фермы. Как проиллюстрировано на рис. 2, получение контроля над учетной записью безопасности SharePoint означает возможность доступа к базе данных конфигурации SharePoint. Эта возможность доступа должна вызвать беспокойство в случае развертывания фермы SharePoint без продумывания защиты учетных записей безопасности, особенно в случае размещения веб-узлов и их коллекций от различных внутренних и внешних клиентов в общей среде.
Рис. 2 Отношения между веб-приложениями SharePoint, базой данных конфигурации и базами данных содержимого Выполнение пользовательского кода на серверах SharePointПо умолчанию SharePoint не раскрывает информацию об учетных записях безопасности, для ее обнаружения необходим вредоносный код. Как мы все знаем, уязвимости безопасности могут позволить взломщикам загрузку такого кода, но порой вторжение еще проще. В простейшем случае злоумышленник может зайти на сервер SharePoint либо локально, либо через службы терминалов и скопировать вредоносный код в папку %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Обратите внимание на то, что SharePoint включает эту папку как виртуализованную подпапку в каждый веб-узел SharePoint. В другом случае SharePoint может ненамеренно ввести вредоносный код, развернув нестандартное решение SharePoint из сомнительного источника, без должного тестирования и проверки кода. Встроенный код ASP.NET в основных страницах и страницах содержимого также является причиной для беспокойства. По умолчанию SharePoint не предоставляет сценарии на стороне сервера, но любой, кто имеет доступ на запись к файлу web.config веб-приложения SharePoint, может изменить правила по обработке сценариев на стороне сервера. Достаточно лишь добавить запись PageParserPath к разделу <PageParserPaths> файла web.config. Каким образом работает запись PageParserPath? Предположим, что разработчик, использующий SharePoint, звонит коллеге и жалуется на сообщение об ошибке, получаемое при разработке собственной страницы ASP.NET, заявляющей: "Code blocks are not allowed in this file" («Блоки кода не допускаются в этом файле»). Коллега обыскивает Интернет и находит решение в группе новостей или на веб-узле блогов: <PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" /> Может быть, он игнорирует предупреждения на тему безопасности, или, возможно, последствия для безопасности даже не упомянуты. Так или иначе, первый разработчик добавляет эту строку к своему файлу web.config, и все счастливы, поскольку он решил проблему. Увы, он, сам того не зная, открыл дорогу для выполнения любого кода на страницах ASP.NET с полным доверием. Если злоумышленник теперь загрузит вредоносную страницу ASP.NET, то среда SharePoint будет в опасности. Как указано на рис. 3, не имеет значения, где в иерархии коллекции веб-узлов у взломщика есть разрешение на загрузку страницы – это может быть невинный на вид веб-узел небольшой группы. Атака всегда поражает веб-приложение и, возможно, всю ферму серверов, поскольку доступными становятся базы данных и содержимого и конфигурации.
Рис. 3. Включение встроенного кода ASP.NET может нарушить безопасность веб-приложения SharePoint Про доктора Джекилла и мистера ХайдаТак как же злоумышленник получает доступ к базам данных и содержимого и конфигурации, не имея прямой информации об учетных данных записи безопасности? На самом деле, довольно прямолинейно. Рабочий процесс IIS, выполняющий веб-приложение SharePoint, олицетворяет пользователя SharePoint и использует получившийся маркер потока для проверок доступа. Например, доктор Джекилл может получить доступ ко всем ресурсам SharePoint, доступ к которым разрешен его маркеру безопасности. Но у веб-приложения SharePoint также есть маркер процесса рабочего процесса IIS, который является маркером безопасности учетной записи безопасности SharePoint. При отмене олицетворения путем вызова статического метода WindowsIdentity.Impersonate и передачи ему нулевого указателя, как проиллюстрировано на рис. 4 и 4a, появляется мистер Хайд. У доктора Джекилла нет прямого доступа к базам данных, но у мистера Хайда есть. Путь открыт для подключений SQL Server и запросов T-SQL.
Рис. 4 У веб-приложений SharePoint существуют два контекста безопасности Рис. 4a. Код для извлечения двух контекстов безопасности веб-приложения SharePoint private string GetMrHyde()
{
string retVal = string.Empty;
retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";
impCtx.Undo();
return retVal;
}Учетные записи безопасности и изоляция процессовПулы приложений и учетные записи безопасности не могут помочь в защите веб-узлов и их коллекций, помещенных в веб-приложение, настроенное на выполнение непроверенного кода. Их целью является смягчение, посредством изоляции, воздействия бреши в защите одного из веб-узлов, позволяющей злоумышленнику внедрять код на сервер для атаки на другие веб-узлы. Изоляция процессов может помочь в достижении этой цели, но она требует помещения других веб-узлов в отдельные веб-приложения, работающие в пулах приложений с различными учетными записями безопасности. Учетные данные записей безопасности необходимо адекватно защитить, в ином случае усилия по конфигурации бессмысленны. Простым способом доставления этих конфиденциальных учетных данных прямо в руки злоумышленника является выдача учетным записям пула приложений доступа к метабазе IIS, требуемого службой управления списками рассылки – частью веб-службы интеграции электронной почты. Если у учетной записи пула приложений есть доступ к метабазе, взломщик может отменить олицетворение и затем получить все учетные записи и пароли в прямом тексте, как показано на рис. 5 и 5a. Вся ферма серверов потеряна, поскольку злоумышленник теперь может обойти изоляцию процессов путем выполнения вредоносного кода от имени любой их этих учетных записей безопасности и установки подключений SQL Server ко всем базам данных содержимого. Рис. 5. Извлечение информации об учетной записи безопасности из метабазы IIS Рис. 5а. Код для извлечения информации об учетной записи безопасности из метабазы IIS private string GetMetabaseAppPoolIDs()
{
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
string retVal = string.Empty;
try
{
string metabasePath = "IIS://localhost/w3svc/AppPools";
DirectoryEntry appPools = new DirectoryEntry(metabasePath);
foreach (DirectoryEntry appPool in appPools.Children)
{
switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
{
case 0: // Local System
retVal += "<br>" + appPool.Name
+ " (Local System)";
break;
case 1: // Local Service
retVal += "<br>" + appPool.Name
+ " (Local Service)";
break;
case 2: // Network Service
retVal += "<br>" + appPool.Name
+ " (Network Service)";
break;
case 3: // Custom
retVal += "<br>" + appPool.Name
+ " (" + appPool.Properties["WAMUserName"].Value
+ " [Pwd: " + appPool.Properties["WAMUserPass"].Value
+ "])";
break;
}
}
}
catch (Exception ee)
{
retVal = "Metabase " + ee.Message;
}
impCtx.Undo();
}Тем, кто заинтересован в решении службы управления списками рассылки, не требующем доступ к метабазе, стоит заглянуть в мою статью за сентябрь 2008 года, «Интеграция каталогов SharePoint». Учетные записи безопасности в базе данных конфигурацииЕсли следовать правилу невыдачи учетным записям пула приложений административных прав или даже доступа на чтение к метабазе IIS на серверах SharePoint, код рис. 5 выдает лишь сообщение Access is denied («В доступе отказано»). Но информация по учетной записи безопасности также доступна в базе данных конфигурации, и у мистера Хайда, как объяснялось выше, есть доступ к этой записи. Учетной записи безопасности SharePoint нельзя запретить доступ к базе данных конфигурации, равно как и доступ к ключу реестра, хранящему соответствующую строку подключения SQL Server. Строка подключения может не сработать немедленно в случае использования SQL Server 2005 Express, но верную информацию об источнике данных можно вывести из текущей коллекции веб-узлов SharePoint (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString), а имя базы данных конфигурации соответствует имени локальной фермы (SPFarm.Local.Name). Увы, эти мелкие препятствия не остановят атаку. Используется ли SQL Server или SQL Server Express, мистер Хайд может получить информацию, отображенную на рис. 6 и 6a. Однако обратите внимание на то, что пароль зашифрован, так что атака пока еще не удалась полностью. Рис. 6. Получение информации об учетной записи безопасности от метабазы конфигурации Рис. 6а. Код для извлечения информации об учетной записи безопасности от метабазы конфигурацииprivate string EnumAppPoolAccounts()
{
string retVal = string.Empty;
try
{
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);
string ConfigDB = (string)keyConfigDB.GetValue("dsn");
SqlConnection sqlConn = new SqlConnection(ConfigDB);
sqlConn.Open();
SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
+ " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
sqlCmd.CommandType = System.Data.CommandType.Text;
SqlDataReader sqlReader = sqlCmd.ExecuteReader();
while (sqlReader.Read())
{
retVal += "<br>" + sqlReader.GetString(0);
string appPoolXML = sqlReader.GetString(1);
if (!string.IsNullOrEmpty(appPoolXML))
{
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(appPoolXML);
XmlElement root = xmlDoc.DocumentElement;
XmlNode ndType = root.SelectSingleNode("/object/fld[@name= 'm_IdentityType']");
if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
{
retVal += " (" + ndType.InnerText + ")";
}
else
{
retVal += " ("
+ root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
+ " [Pwd: "
+ root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
+ "])";
}
}
}
sqlReader.Close();
sqlConn.Close();
impCtx.Undo();
}
catch (Exception ee)
{
retVal = ee.Message;
}
return retVal;
}Но даже без расшифровки паролей пулы приложений, использующие одну и ту же учетную запись безопасности, уже можно распознать. Например, на рис. 6 пулы приложения SharePoint Central Administration v3 и SharePoint—80 используют учетную запись Network Service («Служба сети»), и, если безопасность SharePoint—80 SharePoint оказывается нарушена, то и безопасность Central Administration v3 нарушается тоже. Соответствующей учетной записью безопасности является учетная запись центрального администрирования, имеющая повышенные права на сервере SharePoint. Ее не следует использовать для стандартных пулов веб-приложений, но мастер настройки продуктов и технологий SharePoint применяет эту конфигурацию по умолчанию в установках на один сервер. Таким образом, просмотр и, при необходимости, изменение конфигурации учетной записи в среде SharePoint очень важны. Дополнительные сведения по этой теме подробно изложены в статье базы знаний Майкрософт «Изменение учетных записей службы и паролей учетных записей службы в SharePoint Server 2007 и Windows SharePoint Services 3.0». Учетные записи безопасности и ключи учетных данныхТак что такого насчет учетной записи центрального администрирования? В первую очередь, в отличие от стандартных учетных записей пула приложений, учетная запись центрального администрирования имеет доступ к месту в реестре, где хранится ключ учетных данных для дешифровки паролей учетной записи безопасности. На рис. 7 показан этот параметр и его установки безопасности по умолчанию. Как можно увидеть, локальные администраторы, группа WSS_RESTRICTED_WPG (содержащая учетную запись центрального администрирования) и учетная запись SYSTEM имеют доступ к этому ключу, а это предполагает, что веб-приложениям SharePoint не следует использовать учетные записи с правами локальных администраторов, учетную запись центрального администрирования или учетную запись SYSTEM. У веб-приложений SharePoint не должно быть возможности получить доступ к ключу учетных данных. Рис. 7. Выделения разрешений для доступа к ключу реестра FarmAdmin Увы, это не значит, что умелый взломщик не сможет определить CredentialKey или пароли учетных записей безопасности, скажем, через перехват маркера SYSTEM, взлом пароля или просто путем размещения вредоносного кода на основных страницах или страницах содержимого для экспортирования ключа учетных данных в незащищенное место и последующего ожидания доступа к веб-узлу пользователя с правами локального администратора. Как можно увидеть, важно не допускать на серверы непроверенного кода. Материалы по SharePoint
Перехват маркера SYSTEM заслуживает более подробного объяснения, поскольку эту форму атаки можно предотвратить, избегая использования встроенных учетных записей системы, таких как запись сетевой службы, для веб-приложений SharePoint. Эта уязвимость была обнаружена Цезарем Церрудо (Cesar Cerrudo), основателем и директором компании Argeniss и он продемонстрировал способ воспользоваться ею на конференции по глубинным вопросам безопасности HITBSecConf2008 в Дубаи, Объединенные Арабские Эмираты. Он показал, как веб-приложение ASP.NET работающее под управлением учетной записи сетевой службы, может внедрить DLL в службу удаленного вызова процедуры (RPC) и затем перехватить маркер безопасности потока в службе RPC, работающей на уровне привилегий SYSTEM. После этого злоумышленнику достаточно передать перехваченный маркер SYSTEM методу WindowsIdentity.Impersonate для получения доступа к параметру реестра CredentialKey и другим защищенным ресурсам. Корпорация Майкрософт подтвердила эту уязвимость, так что следует избегать использования учетной записи сетевой службы для веб-приложений SharePoint. Не нарушайте закон10 непреложных законов безопасности были опубликованы центром технической поддержки и безопасности Майкрософт уже давно и остаются в силе по сей день. Йеспер М. Йоханссон (Jesper M. Johansson) недавно написал статью из трех частей, именуемую «Возвращаясь к 10 непреложным законам безопасности». Эти законы следует держать в уме при разработке ферм серверов SharePoint, равно как стоит следовать рекомендациям и памяткам SharePoint для применения надежных настроек учетных записей безопасности. Вкратце: используйте надежные пароли, не давайте учетным записям безопасности повышенные права на серверах SharePoint, меняйте пароли (включая учетные данные фермы) часто и держите в уме, что абсолютной изоляции между приложениями SharePoint, использующими общие ресурсы, не бывает, как не бывает и абсолютной безопасности вообще. Кроме того, не меняйте правила обработки кода сервером, держите непроверенные сборки подальше от серверов и следуйте памятке по требованиям к учетным записям безопасности служб Windows SharePoint при настройке учетных записей, и среду SharePoint можно будет счесть достаточно безопасной. Но если требованием организации является строгое разделение содержимого веб-узлов, я рекомендую размещать соответствующие коллекции веб-узлов в отдельных фермах серверов, возможно, в различных лесах Active Directory и средах SQL Server.
Теги:
Sharepoint.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.gif)
.gif)
.gif)
.gif)
.gif)
.gif)
.gif)
