Еще в апреле я раскрыл две уязвимости в Cloud Foundry UAA (учетная запись пользователя и сервер аутентификации), которые назначили им CVE-2019-11268 и CVE-2019-11270. В своем последнем посте я рассмотрел CVE-2019-11268, SQL-инъекцию, которая позволяла получать информацию в зонах идентификации UAA.
Я не мог обсуждать CVE-2019-11270 вплоть до прошлой недели (1-8-19), пока CF публично не выпустили исправленную версию - UAA v73.7 . CVE-2019-11270 - это уязвимость, связанная с повышением привилегий высокой степени серьезности в реализации UAA области client.write (т. Е. Разрешения). Злонамеренный клиент, обладающий уязвимой областью действия, может создавать новых клиентов с произвольными областями действия и получать полный контроль над сервером UAA и приложениями, которыми он управляет (например, развертывания CF).
Если вы используете UAA в качестве автономного сервера Oauth2 или в развертывании CF, я настоятельно рекомендую вам прочитать раздел «Был ли я затронут?» в конце. Он включает в себя несколько простых команд, которые определят, была ли уязвимость использована в вашей среде.
UAA
Cloud Foundry UAA (учетная запись пользователя и аутентификация) - это сервер Oauth2, обеспечивающий управление идентификацией и контроль доступа. Он может использоваться в качестве сервера Oauth2 в любой среде, в том числе вне развертываний CF.
В моем предыдущем посте я частично затронул такие понятия UAA, как токены доступа, клиенты и области действия. Тем не менее, давайте вернемся к ним с некоторыми иллюстрациями, поскольку понимание их является ключом к пониманию как основных потоков Oauth2, так и уязвимости.
oauth2
Сервер UAA реализует широко используемый протокол авторизации Oauth2. Большинство из вас, вероятно, использовали авторизацию на основе Oauth, например, при регистрации на веб-сайте, таком как eBay, с использованием своей учетной записи Facebook, и авторизации веб-сайта для получения некоторых прав доступа к учетной записи, например, для чтения вашего адреса электронной почты или публикации от вашего имени. Упрощенно, поток авторизации Oauth2 обычно состоит из следующих шагов:
Давайте рассмотрим кусочки на изображении выше:
Серверы ресурсов и токены доступа
Серверы ресурсов определяются как любой объект, который учитывает маркеры доступа, выпущенные UAA, что позволяет UAA управлять доступом к своим ресурсам. Сервер ресурсов может быть базой данных, конечной точкой API или даже самим сервером Oauth2.
Маркер доступа позволяет получить доступ на основе областей (в основном с разрешениями), закодированных в нем. Области - это произвольные строки, к которым серверы ресурсов могут придать значение. Например, приложение базы данных может решить, что любому клиенту, который представляет токен доступа с областью действия db.read, разрешено чтение из него, в то время как другие приложения могут не придавать никакого значения этой области.
Клиенты и пользователи
Клиенты представляют приложения, которым требуется доступ к серверам ресурсов, управляемым UAA. У клиентов есть два набора разрешений - области действия и полномочия .
Пользователь обычно представляет живого человека. Пользователи имеют разрешение в форме членства в группах, например, пользователь, который является членом группы db.read . Однако пользователи не могут напрямую влиять на свои разрешения и могут разрешать клиентам действовать только от их имени.
UAA Access Token Grant
Сервер UAA предоставляет токены доступа клиентам в форме авторизации. Токены предоставляются в двух сценариях:
2. Когда клиент действует самостоятельно. Маркер доступа позволяет клиенту действовать на основании полномочий клиента.
В обоих случаях клиент может представить токен доступа на сервер ресурсов и действовать на основе областей, закодированных в токене.
Как показано выше, некоторые клиенты могут действовать самостоятельно без необходимости одобрения пользователя, в соответствии с набором полномочий. Они полезны для ресурсов, которые не связаны с пользователями. К примеру, Facebook и eBay могут иметь полномочия advertise.put, позволяющие размещать рекламу на Facebook или других сайтах.
Области управления UAA
Несколько областей, называемых « областями UAA », позволяют управлять самим сервером UAA. Например, после того, как клиент с полномочиями «groups.update» аутентифицируется на сервере UAA и получает токен доступа, он может представить этот токен доступа в UAA, а затем ему будет разрешено изменять существующие группы. В случае с областями управления, UAA также играет роль сервера ресурсов.
Вот и все, что касается фона Oauth2 & UAA, а теперь о важных деталях.
CVE-2019-11270 - Повышение привилегий через область client.write
clients.write - это одна из областей управления UAA, о которой я упоминал ранее, и она является более узкой версией client.admin. Подобно clients.admin, clients.write позволяет создавать и изменять клиентов, но накладывает несколько ограничений на создаваемых клиентов. «clients.write» документируется следующим образом:
Таким образом, созданным клиентам разрешено иметь префиксы областей только с идентификатором создаваемого клиента. Например, клиент с идентификатором «app123» и полномочиями: clients.write может регистрировать только новых клиентов с областями, в которых префикс app123. (например, app123.read или app123.admin ). Предполагается, что эти ограничения не позволят клиенту с областью client.write создавать клиентов с привилегированными областями управления UAA (например, uaa.admin ) и расширять его привилегии.
Вариант использования "Client.write"
Область client.write удобна для управления сервером ресурсов. Для управления приложением базы данных администратор UAA может создать клиента с идентификатором «db» и предоставить ему полномочияclient.write. Клиент 'db' теперь может создавать новых клиентов и предоставлять им области с префиксом db. как db.read , db.create или db.admin . Клиент db фактически является административным клиентом для приложения базы данных и может создавать других клиентов с детальными разрешениями для приложения.
Поскольку созданные клиенты могут быть зарегистрированы только с областями, а не с правами доступа, все они требуют, чтобы пользователь их авторизовал для получения токена доступа (как показано выше в разделе «Предоставление токена доступа»). В производственной среде клиенту 'db' могут быть предоставлены полномочия scim.write и scim.read, чтобы он мог создавать пользователей с соответствующим членством в группах (например, db.read ), чтобы они могли авторизовать новых клиентов.
Уязвимость
Изучив код UAA который следит за соблюдением указанных выше ограничений, в частности ClientAdminEndpointValidator в функцию Validate, оказывается, что clients.write не реализовано:
В приведенном выше коде «caller» относится к создающему клиенту (т. Е. Клиенту, обладающему областью client.write ), а «client» относится к созданному клиенту.
Вы можете увидеть, что помимо разрешения областей с префиксом создаваемого идентификатора клиента (как описано), функция также позволяет областям с префиксом созданного идентификатора клиента иметь такие-же разрешения. Этот недостаток реализации позволяет вызывающей стороне создавать клиентов с произвольными областями, так как он также контролирует созданный идентификатор клиента.
Злонамеренный клиент с полномочиями client.write может, например, создать клиента с идентификатором id: 'zone' и, следовательно, с любой областью действия с префиксом зон. , например zone.uaa.admin , область, которая обеспечивает полный административный контроль над сервером UAA.
Как примечание, в строке # 182 вы можете видеть, что клиент-создатель может также назначить любую из своих собственных областей. Это имеет смысл, поскольку у создавающего клиента уже есть эти области, поэтому передача их новому клиенту не повышает его привилегии.
Explotation
Как указывалось ранее, клиентам, желающим действовать в своих областях, требуется пользователь с соответствующим членством в группе для их авторизации. Злоумышленнику, воспользовавшемуся этой уязвимостью для создания клиента с идентификатором id: ' zone ' и scopes: zone.write , например, понадобится пользователь, который является членом группы zone.write, чтобы авторизовать нового клиента зон.
Если этот злоумышленник контролирует такого пользователя, атака становится тривиальной. То же самое верно, если злоумышленник имеет привилегии scim, то есть scim.write и scim.read , которые дают ему возможность создать требуемого пользователя.
Эта атака продемонстрирована в видео ниже, где «злой» клиент использует уязвимость для получения токена доступа с областью Clients.admin, получая полный контроль над сервером UAA.
Видео не может быть перенесено на форум, поэтому вы можете посмотреть его в оригинальной статье: https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/
Это лучший вариант для злоумышленника, хотя, помимо наличия уязвимой области client.write, он также имеет доступ к пользователям, которые могут утверждать клиентов, созданных с учетом этой уязвимости. Давайте немного ограничим нашего злоумышленника. Что он может делать только с уязвимой областью? Является ли уязвимость бесполезной в этом случае?
Автоматически утвержденные Области
К счастью для нашего ограниченного злоумышленника, область client.write также позволяет использовать функцию автоматического одобрения UAA. Обычно, когда пользователь разрешает клиенту действовать от его имени, ему предоставляется возможность одобрить или отклонить запрос области действия клиентом. Как видно на рисунке выше, пользователь решил утвердить только область действия database.read. Если для одной из областей клиента было установлено автоматическое одобрение, область действия автоматически, без ведома или согласия пользователя. Например, на изображении выше область database.admin утверждена автоматически, и вы можете видеть, что у пользователя нет никаких указаний на это.
Автоматически утверждать эксплойт
Как я уже говорил ранее, область client.write позволяет устанавливать области автоматически создаваемых клиентов. Давайте посмотрим, как злоумышленник может использовать эту функцию, чтобы получить полный контроль над развертыванием CF в сценарии, имитирующем реальную производственную среду.
В предыдущем видео об эксплойте злоумышленник имел доступ к области client.write в виде клиента с правами client.write. Для этого сценария, злоумышленник имеет доступ к clients.write объема через классический пользователь-клиент пару oauth2:
Цель злоумышленника - использовать уязвимость, чтобы добавить область «cloud_controller.admin» к клиенту
Атака
Если вы не уверены, как злоумышленнику удалось выполнить один из следующих шагов, вы, вероятно, получите некоторые пояснения в главе « Уязвимость» .
2. Затем злоумышленник использует пользователя
3. В следующий раз, когда
Эта атака успешно выполнена в видео ниже:
Видео не может быть перенесено на форум, поэтому вы можете посмотреть его в оригинальной статье: https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/
После выполнения атаки клиент
В видео я использовал uaac, CLI для сервера UAA. В реальной ситуации атаки клиент
Я был затронут?
Ниже приведена пара команд uaac (uaa CLI), чтобы проверить, эксплуатировался ли CVE-2019-11270 в вашей среде.
Имейте в виду, что злоумышленник мог удалить клиентов, которых он создал с помощью этой уязвимости, поэтому вы можете также проверить журналы UAA.
Конец
Я надеюсь, что этот пост помог вам понять уязвимость, методы ее использования и влияние.
Если вы используете либо Cloud Foundry Application Runtime, либо UAA, не забудьте обновить его до последней исправленной версии .
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/
Я не мог обсуждать CVE-2019-11270 вплоть до прошлой недели (1-8-19), пока CF публично не выпустили исправленную версию - UAA v73.7 . CVE-2019-11270 - это уязвимость, связанная с повышением привилегий высокой степени серьезности в реализации UAA области client.write (т. Е. Разрешения). Злонамеренный клиент, обладающий уязвимой областью действия, может создавать новых клиентов с произвольными областями действия и получать полный контроль над сервером UAA и приложениями, которыми он управляет (например, развертывания CF).
Если вы используете UAA в качестве автономного сервера Oauth2 или в развертывании CF, я настоятельно рекомендую вам прочитать раздел «Был ли я затронут?» в конце. Он включает в себя несколько простых команд, которые определят, была ли уязвимость использована в вашей среде.
UAA
Cloud Foundry UAA (учетная запись пользователя и аутентификация) - это сервер Oauth2, обеспечивающий управление идентификацией и контроль доступа. Он может использоваться в качестве сервера Oauth2 в любой среде, в том числе вне развертываний CF.
В моем предыдущем посте я частично затронул такие понятия UAA, как токены доступа, клиенты и области действия. Тем не менее, давайте вернемся к ним с некоторыми иллюстрациями, поскольку понимание их является ключом к пониманию как основных потоков Oauth2, так и уязвимости.
oauth2
Сервер UAA реализует широко используемый протокол авторизации Oauth2. Большинство из вас, вероятно, использовали авторизацию на основе Oauth, например, при регистрации на веб-сайте, таком как eBay, с использованием своей учетной записи Facebook, и авторизации веб-сайта для получения некоторых прав доступа к учетной записи, например, для чтения вашего адреса электронной почты или публикации от вашего имени. Упрощенно, поток авторизации Oauth2 обычно состоит из следующих шагов:
Давайте рассмотрим кусочки на изображении выше:
Серверы ресурсов и токены доступа
Серверы ресурсов определяются как любой объект, который учитывает маркеры доступа, выпущенные UAA, что позволяет UAA управлять доступом к своим ресурсам. Сервер ресурсов может быть базой данных, конечной точкой API или даже самим сервером Oauth2.
Маркер доступа позволяет получить доступ на основе областей (в основном с разрешениями), закодированных в нем. Области - это произвольные строки, к которым серверы ресурсов могут придать значение. Например, приложение базы данных может решить, что любому клиенту, который представляет токен доступа с областью действия db.read, разрешено чтение из него, в то время как другие приложения могут не придавать никакого значения этой области.
Клиенты и пользователи
Клиенты представляют приложения, которым требуется доступ к серверам ресурсов, управляемым UAA. У клиентов есть два набора разрешений - области действия и полномочия .
Пользователь обычно представляет живого человека. Пользователи имеют разрешение в форме членства в группах, например, пользователь, который является членом группы db.read . Однако пользователи не могут напрямую влиять на свои разрешения и могут разрешать клиентам действовать только от их имени.
UAA Access Token Grant
Сервер UAA предоставляет токены доступа клиентам в форме авторизации. Токены предоставляются в двух сценариях:
- Когда клиент действует от имени пользователя (аналогично примеру Facebook и изображению под ним).
Здесь маркер доступа разрешает клиенту действовать на основе пересечения областей клиента и пользователя в группах (например, клиент с db.read объема и пользователь, который является членом db.read группы). Пользователь также может подтвердить или отклонить области, запрошенные клиентом.
2. Когда клиент действует самостоятельно. Маркер доступа позволяет клиенту действовать на основании полномочий клиента.
В обоих случаях клиент может представить токен доступа на сервер ресурсов и действовать на основе областей, закодированных в токене.
Как показано выше, некоторые клиенты могут действовать самостоятельно без необходимости одобрения пользователя, в соответствии с набором полномочий. Они полезны для ресурсов, которые не связаны с пользователями. К примеру, Facebook и eBay могут иметь полномочия advertise.put, позволяющие размещать рекламу на Facebook или других сайтах.
Области управления UAA
Несколько областей, называемых « областями UAA », позволяют управлять самим сервером UAA. Например, после того, как клиент с полномочиями «groups.update» аутентифицируется на сервере UAA и получает токен доступа, он может представить этот токен доступа в UAA, а затем ему будет разрешено изменять существующие группы. В случае с областями управления, UAA также играет роль сервера ресурсов.
Вот и все, что касается фона Oauth2 & UAA, а теперь о важных деталях.
CVE-2019-11270 - Повышение привилегий через область client.write
clients.write - это одна из областей управления UAA, о которой я упоминал ранее, и она является более узкой версией client.admin. Подобно clients.admin, clients.write позволяет создавать и изменять клиентов, но накладывает несколько ограничений на создаваемых клиентов. «clients.write» документируется следующим образом:
Таким образом, созданным клиентам разрешено иметь префиксы областей только с идентификатором создаваемого клиента. Например, клиент с идентификатором «app123» и полномочиями: clients.write может регистрировать только новых клиентов с областями, в которых префикс app123. (например, app123.read или app123.admin ). Предполагается, что эти ограничения не позволят клиенту с областью client.write создавать клиентов с привилегированными областями управления UAA (например, uaa.admin ) и расширять его привилегии.
Вариант использования "Client.write"
Область client.write удобна для управления сервером ресурсов. Для управления приложением базы данных администратор UAA может создать клиента с идентификатором «db» и предоставить ему полномочияclient.write. Клиент 'db' теперь может создавать новых клиентов и предоставлять им области с префиксом db. как db.read , db.create или db.admin . Клиент db фактически является административным клиентом для приложения базы данных и может создавать других клиентов с детальными разрешениями для приложения.
Поскольку созданные клиенты могут быть зарегистрированы только с областями, а не с правами доступа, все они требуют, чтобы пользователь их авторизовал для получения токена доступа (как показано выше в разделе «Предоставление токена доступа»). В производственной среде клиенту 'db' могут быть предоставлены полномочия scim.write и scim.read, чтобы он мог создавать пользователей с соответствующим членством в группах (например, db.read ), чтобы они могли авторизовать новых клиентов.
Уязвимость
Изучив код UAA который следит за соблюдением указанных выше ограничений, в частности ClientAdminEndpointValidator в функцию Validate, оказывается, что clients.write не реализовано:
В приведенном выше коде «caller» относится к создающему клиенту (т. Е. Клиенту, обладающему областью client.write ), а «client» относится к созданному клиенту.
Вы можете увидеть, что помимо разрешения областей с префиксом создаваемого идентификатора клиента (как описано), функция также позволяет областям с префиксом созданного идентификатора клиента иметь такие-же разрешения. Этот недостаток реализации позволяет вызывающей стороне создавать клиентов с произвольными областями, так как он также контролирует созданный идентификатор клиента.
Злонамеренный клиент с полномочиями client.write может, например, создать клиента с идентификатором id: 'zone' и, следовательно, с любой областью действия с префиксом зон. , например zone.uaa.admin , область, которая обеспечивает полный административный контроль над сервером UAA.
Как примечание, в строке # 182 вы можете видеть, что клиент-создатель может также назначить любую из своих собственных областей. Это имеет смысл, поскольку у создавающего клиента уже есть эти области, поэтому передача их новому клиенту не повышает его привилегии.
Explotation
Как указывалось ранее, клиентам, желающим действовать в своих областях, требуется пользователь с соответствующим членством в группе для их авторизации. Злоумышленнику, воспользовавшемуся этой уязвимостью для создания клиента с идентификатором id: ' zone ' и scopes: zone.write , например, понадобится пользователь, который является членом группы zone.write, чтобы авторизовать нового клиента зон.
Если этот злоумышленник контролирует такого пользователя, атака становится тривиальной. То же самое верно, если злоумышленник имеет привилегии scim, то есть scim.write и scim.read , которые дают ему возможность создать требуемого пользователя.
Эта атака продемонстрирована в видео ниже, где «злой» клиент использует уязвимость для получения токена доступа с областью Clients.admin, получая полный контроль над сервером UAA.
Видео не может быть перенесено на форум, поэтому вы можете посмотреть его в оригинальной статье: https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/
Это лучший вариант для злоумышленника, хотя, помимо наличия уязвимой области client.write, он также имеет доступ к пользователям, которые могут утверждать клиентов, созданных с учетом этой уязвимости. Давайте немного ограничим нашего злоумышленника. Что он может делать только с уязвимой областью? Является ли уязвимость бесполезной в этом случае?
Автоматически утвержденные Области
К счастью для нашего ограниченного злоумышленника, область client.write также позволяет использовать функцию автоматического одобрения UAA. Обычно, когда пользователь разрешает клиенту действовать от его имени, ему предоставляется возможность одобрить или отклонить запрос области действия клиентом. Как видно на рисунке выше, пользователь решил утвердить только область действия database.read. Если для одной из областей клиента было установлено автоматическое одобрение, область действия автоматически, без ведома или согласия пользователя. Например, на изображении выше область database.admin утверждена автоматически, и вы можете видеть, что у пользователя нет никаких указаний на это.
Автоматически утверждать эксплойт
Как я уже говорил ранее, область client.write позволяет устанавливать области автоматически создаваемых клиентов. Давайте посмотрим, как злоумышленник может использовать эту функцию, чтобы получить полный контроль над развертыванием CF в сценарии, имитирующем реальную производственную среду.
В предыдущем видео об эксплойте злоумышленник имел доступ к области client.write в виде клиента с правами client.write. Для этого сценария, злоумышленник имеет доступ к clients.write объема через классический пользователь-клиент пару oauth2:
twistпользователя , который является членом clients.write сферыevilклиент, который имеет clients.write сферы, наряду с some.arbitrary рамки (будет объяснено в ближайшее время)
- Приложение
some-fake- сервер ресурсов, который доверяет токенам доступа UAA для управления доступом к своим ресурсам. Требуется, чтобы токен содержал произвольную область видимости. - Пользователь
victim- член групп some.arbitrary и cloud_controller.admin .
victim регулярно утверждает, что клиент evil использует область some.arbitrary и получает доступ к приложению some-fake от своего имени.
Цель злоумышленника - использовать уязвимость, чтобы добавить область «cloud_controller.admin» к клиенту
evil и установить её как автоматически утвержденную.Атака
Если вы не уверены, как злоумышленнику удалось выполнить один из следующих шагов, вы, вероятно, получите некоторые пояснения в главе « Уязвимость» .
- Чтобы начать атаку, злоумышленник использует пользователя
twistиevil, чтобы получить токен доступа с областью уязвимых клиентов . Затем он использует уязвимость для создания клиента с именем cloud_contoller и предоставляет ему область cloud_contoller.admin. Атакующий также предоставляет клиенту «cloud_contoller» все возможности пользователяevil.
2. Затем злоумышленник использует пользователя
twist и клиента «cloud_contoller», чтобы изменить клиента evil так, чтобы он имел область действия cloud_controller.admin, а также установить его как автоматически утвержденный.
3. В следующий раз, когда
victim разрешит клиенту evil использовать область some.arbitrary, область cloud_controller.admin будет также автоматически утверждена без согласия жертвы (!):
Эта атака успешно выполнена в видео ниже:
Видео не может быть перенесено на форум, поэтому вы можете посмотреть его в оригинальной статье: https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/
После выполнения атаки клиент
evil имеет административный контроль над cloud_controller, что означает полный контроль над развертыванием CFВ видео я использовал uaac, CLI для сервера UAA. В реальной ситуации атаки клиент
evil, скорее всего, будет иметь веб-интерфейс, и victim перенаправит пользователя с него на страницы аутентификации и авторизации UAA.Я был затронут?
Ниже приведена пара команд uaac (uaa CLI), чтобы проверить, эксплуатировался ли CVE-2019-11270 в вашей среде.
Код:
## Configure the uaa client
uaac target ${uaa-url} --skip-ssl-validation # set the UAA api endpoint
uaac token client get admin -s $uaa_admin_client_secret # authenticate as the UAA admin (any client with the 'clients.read' authority will do)
## If any of the following queries finds matching clients, your UAA server was likely attacked using CVE-2019-11270.
# Check for UAA management scopes:
uaac clients "client_id eq 'clients' or client_id eq 'scim' or client_id eq 'groups' or client_id sw 'zones'"
uaac clients "client_id eq 'password' or client_id eq 'idps' or client_id eq 'oauth'"
# Check for Cloud Foundry scopes:
uaac clients "client_id eq 'cloud_controller' or client_id eq 'routing' or client_id eq 'doppler' or client_id eq 'notifications'"Имейте в виду, что злоумышленник мог удалить клиентов, которых он создал с помощью этой уязвимости, поэтому вы можете также проверить журналы UAA.
Конец
Я надеюсь, что этот пост помог вам понять уязвимость, методы ее использования и влияние.
Если вы используете либо Cloud Foundry Application Runtime, либо UAA, не забудьте обновить его до последней исправленной версии .
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://www.twistlock.com/labs-blog/privilege-escalation-in-cloud-foundry-uaa-cve-2019-11270/