Az - OAuth Apps Phishing

Reading time: 7 minutes

OAuth App Phishing

Azure Applications는 사용자가 애플리케이션에 동의할 때 사용할 수 있는 권한으로 구성됩니다(예: 디렉토리 열거, 파일 접근 또는 기타 작업 수행). 애플리케이션은 사용자를 대신하여 작동하므로, 애플리케이션이 관리 권한을 요청할 수 있더라도 사용자가 해당 권한을 가지고 있지 않으면, 애플리케이션은 관리 작업을 수행할 수 없습니다.

App consent permissions

기본적으로 모든 사용자는 앱에 동의할 수 있습니다, 하지만 이는 사용자가 선택된 권한에 대해 검증된 게시자의 앱에만 동의할 수 있도록 구성할 수 있으며, 심지어 사용자가 애플리케이션에 동의할 권한을 제거할 수도 있습니다.

사용자가 동의할 수 없는 경우, GA, Application Administrator 또는 Cloud Application Administrator와 같은 관리자가 사용자가 사용할 수 있는 애플리케이션에 동의할 수 있습니다.

또한, 사용자가 저위험 권한을 사용하는 앱에만 동의할 수 있는 경우, 이러한 권한은 기본적으로 openid, profile, email, User.Read 및 offline_access이며, 이 목록에 더 많은 권한을 추가할 수 있습니다.

사용자가 모든 앱에 동의할 수 있다면, 모든 앱에 동의할 수 있습니다.

2 Types of attacks

• Unauthenticated: 외부 계정에서 저위험 권한인 User.Read 및 User.ReadBasic.All을 가진 애플리케이션을 생성하고 사용자를 피싱하면 디렉토리 정보에 접근할 수 있습니다.
• 피싱된 사용자가 외부 테넌트의 OAuth 앱을 수락할 수 있어야 합니다.
• 피싱된 사용자가 모든 권한을 가진 어떤 앱에도 동의할 수 있는 관리자인 경우, 애플리케이션은 특권 권한을 요청할 수도 있습니다.
• Authenticated: 충분한 권한을 가진 주체를 손상시킨 후, 계정 내에서 애플리케이션을 생성하고 특권 OAuth 권한을 수락할 수 있는 특권 사용자를 피싱합니다.
• 이 경우 이미 디렉토리 정보를 접근할 수 있으므로, 권한 User.ReadBasic.All은 더 이상 흥미롭지 않습니다.
• 관리자가 부여해야 하는 권한에 관심이 있을 가능성이 높습니다. 일반 사용자는 OAuth 앱에 어떤 권한도 부여할 수 없기 때문에, 오직 이러한 사용자만 피싱해야 합니다(어떤 역할/권한이 이 특권을 부여하는지에 대한 내용은 나중에 설명).

Users are allowed to consent

테넌트 내의 사용자로부터 이 명령을 실행해야 하며, 외부에서 테넌트의 이 구성을 찾을 수 없습니다. 다음 CLI는 사용자의 권한을 이해하는 데 도움이 될 수 있습니다:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"

• 모든 앱에 대한 사용자 동의: permissionGrantPoliciesAssigned 내에 ManagePermissionGrantsForSelf.microsoft-user-default-legacy가 있으면 사용자가 모든 애플리케이션을 수락할 수 있습니다.
• 사용자는 검증된 게시자 또는 귀하의 조직의 앱에 동의할 수 있지만, 선택한 권한에 대해서만 가능합니다: permissionGrantPoliciesAssigned 내에 ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team가 있으면 사용자가 모든 애플리케이션을 수락할 수 있습니다.
• 사용자 동의 비활성화: permissionGrantPoliciesAssigned 내에 ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat와 ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team만 있으면 사용자가 동의할 수 없습니다.

주석이 달린 각 정책의 의미를 찾는 것은 가능합니다:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

애플리케이션 관리자

새로운 애플리케이션을 수락할 수 있는 애플리케이션 관리자라고 간주되는 사용자를 확인하십시오:

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

공격 흐름 개요

이 공격은 일반적인 회사를 목표로 하는 여러 단계를 포함합니다. 다음은 공격이 어떻게 전개될 수 있는지에 대한 설명입니다:

1. 도메인 등록 및 애플리케이션 호스팅: 공격자는 신뢰할 수 있는 사이트를 닮은 도메인을 등록합니다. 예를 들어, "safedomainlogin.com"과 같은 도메인입니다. 이 도메인 아래에 서브도메인(예: "companyname.safedomainlogin.com")이 생성되어 권한 부여 코드를 캡처하고 액세스 토큰을 요청하는 애플리케이션을 호스팅합니다.
2. Azure AD에서 애플리케이션 등록: 공격자는 자신의 Azure AD 테넌트에 다중 테넌트 애플리케이션을 등록하고, 이를 목표 회사의 이름으로 명명하여 합법적으로 보이게 합니다. 그들은 애플리케이션의 리디렉션 URL을 악성 애플리케이션을 호스팅하는 서브도메인으로 설정합니다.
3. 권한 설정: 공격자는 애플리케이션에 다양한 API 권한(예: Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)을 설정합니다. 이러한 권한은 사용자가 부여하면 공격자가 사용자를 대신하여 민감한 정보를 추출할 수 있게 합니다.
4. 악성 링크 배포: 공격자는 악성 애플리케이션의 클라이언트 ID를 포함하는 링크를 작성하고 이를 목표 사용자와 공유하여 그들이 동의를 하도록 속입니다.

예시 공격

1. 새 애플리케이션을 등록합니다. 공격받는 디렉토리의 사용자라면 현재 디렉토리만 사용할 수 있으며, 외부 공격이라면 모든 디렉토리에 대해 사용할 수 있습니다(다음 이미지와 같이).
2. 또한 리디렉션 URI를 토큰을 얻기 위해 코드를 받을 예상 URL로 설정합니다(http://localhost:8000/callback가 기본값입니다).

2. 그런 다음 애플리케이션 비밀을 생성합니다:

3. API 권한을 선택합니다(예: Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. 권한을 요청하는 웹 페이지 (azure_oauth_phishing_example**)**를 실행합니다:

# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"

5. 피해자에게 URL 전송
6. 이 경우 http://localhost:8000
7. 피해자는 프롬프트를 수락해야 합니다:

7. 요청된 권한에 접근하기 위해 액세스 토큰을 사용하세요:

export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

기타 도구

• 365-Stealer: https://www.alteredsecurity.com/post/introduction-to-365-stealer에서 설정 방법을 확인하세요.
• O365-Attack-Toolkit

포스트 익스플로잇

피싱 포스트 익스플로잇

요청된 권한에 따라 테넌트의 다양한 데이터에 접근할 수 있을 수 있습니다 (사용자 목록, 그룹... 또는 설정 수정) 및 사용자 정보 (파일, 노트, 이메일...). 그런 다음 이러한 권한을 사용하여 해당 작업을 수행할 수 있습니다.

Entra ID 애플리케이션 관리자

어떻게든 Entra ID에서 애플리케이션을 관리할 수 있는 Entra ID 주체를 손상시켰다면, 사용자가 사용하는 애플리케이션이 있을 수 있습니다. 관리자는 앱이 요청하는 권한을 수정하고 토큰을 훔치기 위해 새로운 허용된 리디렉션 주소를 추가할 수 있습니다.

• 리디렉션 URI를 추가하는 것이 가능하다는 점에 유의하세요 (실제 URI를 삭제할 필요 없음) 그리고 공격자의 리디렉션 URI를 사용하여 HTTP 링크를 전송하면 사용자가 링크를 따를 때 인증이 자동으로 발생하고 공격자가 토큰을 받게 됩니다.
• 또한 앱이 사용자로부터 더 많은 권한을 얻기 위해 요청하는 권한을 변경하는 것도 가능하지만, 이 경우 사용자는 프롬프트를 다시 수락해야 합니다 (이미 로그인한 경우에도).
• 이 공격을 수행하기 위해 공격자는 애플리케이션 코드를 제어할 필요가 없습니다. 그는 단지 새로운 URL을 redirect_uri 매개변수에 포함하여 사용자가 앱에 로그인하도록 링크를 보낼 수 있습니다.

애플리케이션 포스트 익스플로잇

페이지의 애플리케이션 및 서비스 주체 섹션을 확인하세요:

Az - EntraID Privesc

참고자료

• https://www.alteredsecurity.com/post/introduction-to-365-stealer
• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/