Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00

Translator workflow 1d9d380da0 Translated to Korean

2024-02-10 21:30:13 +00:00

19 KiB

Raw Blame History

OAuth를 통한 계정 탈취

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!
공식 PEASS & HackTricks 스웨그를 얻으세요.
The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.
💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm를 팔로우하세요.
HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

기본 정보

OAuth는 여러 버전을 제공하며, 기본적인 내용은 OAuth 2.0 문서에서 확인할 수 있습니다. 이 토론은 주로 널리 사용되는 OAuth 2.0 인가 코드 그랜트 타입에 중점을 두며, 이는 응용 프로그램이 다른 응용 프로그램(인증 서버)의 사용자 계정에 액세스하거나 작업을 수행할 수 있는 인가 프레임워크를 제공합니다.

가상의 웹사이트 _https://example.com_을 고려해보겠습니다. 이 웹사이트는 사용자의 모든 소셜 미디어 게시물을 보여주는 것이 목적입니다. 이를 위해 OAuth 2.0이 사용됩니다. _https://example.com_은 사용자의 소셜 미디어 게시물에 액세스하기 위한 권한을 요청합니다. 이에 따라 _https://socialmedia.com_에서 동의 화면이 나타나며, 요청하는 권한과 요청을 하는 개발자가 설명됩니다. 사용자의 승인 후, _https://example.com_은 사용자를 대신하여 게시물에 액세스할 수 있는 권한을 얻게 됩니다.

OAuth 2.0 프레임워크 내에서 다음 구성 요소를 이해하는 것이 중요합니다:

리소스 소유자: 사용자/개체로서 소셜 미디어 계정 게시물과 같은 리소스에 대한 액세스를 승인합니다.
리소스 서버: 응용 프로그램이 리소스 소유자를 대신하여 액세스 토큰을 확보한 후 인증된 요청을 관리하는 서버, 예: https://socialmedia.com.
클라이언트 응용 프로그램: 리소스 소유자로부터 인가를 요청하는 응용 프로그램, 예: https://example.com.
인가 서버: 리소스 소유자의 성공적인 인증 및 인가 후 클라이언트 응용 프로그램에 액세스 토큰을 발급하는 서버, 예: https://socialmedia.com.
client_id: 응용 프로그램을 고유하게 식별하는 공개 식별자입니다.
client_secret: 응용 프로그램과 인가 서버만이 알고 있는 비밀 키로, 액세스 토큰을 생성하는 데 사용됩니다.
response_type: code와 같은 요청하는 토큰의 유형을 지정하는 값입니다.
scope: 클라이언트 응용 프로그램이 리소스 소유자로부터 요청하는 액세스 수준입니다.
redirect_uri: 사용자가 인가 후 리디렉션되는 URL입니다. 일반적으로 미리 등록된 리디렉션 URL과 일치해야 합니다.
state: 사용자가 인가 서버로부터 리디렉션되고 다시 리디렉션되는 동안 데이터를 유지하기 위한 매개 변수입니다. 고유성은 CSRF 보호 메커니즘으로서 중요합니다.
grant_type: 인가 유형과 반환될 토큰의 유형을 나타내는 매개 변수입니다.
code: 인가 서버에서 받은 인가 코드로, client\_id와 client\_secret과 함께 클라이언트 응용 프로그램이 액세스 토큰을 얻는 데 사용합니다.
access_token: 리소스 소유자를 대신하여 클라이언트 응용 프로그램이 API 요청에 사용하는 토큰입니다.
refresh_token: 사용자에게 다시 확인을 요청하지 않고 새로운 액세스 토큰을 얻을 수 있게 하는 응용 프로그램입니다.

플로우

실제 OAuth 플로우는 다음과 같이 진행됩니다:

https://example.com으로 이동하여 "소셜 미디어와 통합" 버튼을 선택합니다.
해당 사이트는 https://example.com의 응용 프로그램이 게시물에 액세스할 수 있도록 권한을 부여하기 위해 https://socialmedia.com에 요청을 보냅니다. 요청은 다음과 같이 구성됩니다:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

그런 다음 동의 페이지가 표시됩니다.
승인 후, 소셜 미디어는 redirect_uri로 code와 state 매개변수를 포함한 응답을 보냅니다:

https://example.com?code=uniqueCode123&state=randomString123

https://example.com은 code와 함께 client_id와 client_secret을 사용하여 서버 측 요청을 수행하여 access_token을 얻습니다. 이를 통해 당신이 동의한 권한에 대한 액세스가 가능해집니다:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

마지막으로, 프로세스는 https://example.com이 access_token을 사용하여 API 호출을 수행하여 소셜 미디어에 액세스합니다.

취약점

Open redirect_uri

redirect_uri는 OAuth 및 OpenID 구현에서 보안에 중요한 역할을 합니다. 이는 인가 후에 인가 코드와 같은 민감한 데이터가 전송되는 위치를 지정하기 때문입니다. 잘못 구성된 경우, 공격자는 이러한 요청을 악성 서버로 리디렉션하여 계정 탈취를 가능하게 할 수 있습니다.

악용 기법은 인가 서버의 유효성 검사 논리에 따라 다양합니다. 엄격한 경로 일치부터 지정된 도메인 또는 하위 디렉토리 내의 모든 URL을 허용하는 것까지 다양합니다. 일반적인 악용 방법으로는 개방형 리디렉트, 경로 순회, 약한 정규식 악용 및 토큰 도난을 위한 HTML 삽입이 있습니다.

redirect_uri 외에도 client_uri, policy_uri, tos_uri, initiate_login_uri와 같은 다른 OAuth 및 OpenID 매개변수도 리디렉션 공격에 취약할 수 있습니다. 이러한 매개변수는 선택적이며 지원 범위는 서버마다 다릅니다.

OpenID 서버를 대상으로 하는 경우, 검색 엔드포인트 (**.well-known/openid-configuration**)는 종종 registration_endpoint, request_uri_parameter_supported, "require_request_uri_registration과 같은 가치 있는 구성 세부 정보를 나열합니다. 이러한 세부 정보는 서버의 등록 엔드포인트 및 기타 구성 세부 정보를 식별하는 데 도움이 될 수 있습니다.

리디렉션 구현에서의 XSS

이 버그 바운티 보고서 https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html에서 언급된 바에 따르면, 사용자가 인증을 완료한 후 서버의 응답에 리디렉트 URL이 반영될 수 있으며, XSS에 취약할 수 있습니다. 테스트할 수 있는 가능한 페이로드:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - 상태 매개변수의 부적절한 처리

OAuth 구현에서 state 매개변수의 오용 또는 생략은 Cross-Site Request Forgery (CSRF) 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 state 매개변수가 사용되지 않거나 정적 값으로 사용되거나 적절하게 유효성을 검사하지 않을 때 발생하며, 이로 인해 공격자가 CSRF 보호를 우회할 수 있습니다.

공격자는 권한 부여 프로세스를 가로채어 희생자의 계정과 자신의 계정을 연결하여 잠재적인 계정 탈취를 유도할 수 있습니다. 이는 특히 OAuth가 인증 목적으로 사용되는 애플리케이션에서 매우 중요합니다.

이러한 취약점의 실제 예는 다양한 CTF 도전과 해킹 플랫폼에서 문서화되어 있으며, 실제적인 영향을 보여줍니다. 이 문제는 또한 Slack, Stripe, PayPal과 같은 제3자 서비스와의 통합에도 영향을 미칩니다. 여기서 공격자는 알림이나 결제를 자신의 계정으로 리디렉션할 수 있습니다.

state 매개변수의 적절한 처리와 유효성 검사는 CSRF를 방지하고 OAuth 플로우를 보호하는 데 중요합니다.

계정 탈취 전 사전 조치

계정 생성 시 이메일 검증 없음: 공격자는 희생자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 희생자가 나중에 로그인을 위해 제3자 서비스를 사용하는 경우, 애플리케이션은 실수로 이 제3자 계정을 공격자가 미리 생성한 계정과 연결할 수 있어 권한 없는 액세스가 발생할 수 있습니다.
유연한 OAuth 이메일 검증 악용: 공격자는 이메일을 검증하지 않는 OAuth 서비스를 악용하여 자신의 서비스에 등록한 후 계정 이메일을 희생자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사한 권한 없는 계정 액세스 위험을 가지며, 다른 공격 벡터를 통해 발생합니다.

비밀 정보 노출

OAuth 매개변수의 비밀을 식별하고 보호하는 것이 중요합니다. **client_id**는 안전하게 공개될 수 있지만, **client_secret**를 공개하면 중대한 위험에 노출됩니다. client_secret이 유출되면 공격자는 애플리케이션의 신원과 신뢰를 악용하여 사용자의 access_token과 개인 정보를 도용할 수 있습니다.

일반적인 취약점은 애플리케이션이 권한 code를 access_token으로 교환하는 과정을 클라이언트 측에서 처리하는 경우 발생합니다. 이 실수로 인해 client_secret이 노출되어 공격자가 애플리케이션의 위장을 한 채로 access_token을 생성할 수 있습니다. 더구나 사회 공학 기법을 통해 공격자는 OAuth 권한에 추가적인 범위를 추가하여 애플리케이션의 신뢰할 수 있는 상태를 악용할 수 있습니다.

클라이언트 시크릿 브루트포스

서비스 제공자의 클라이언트 시크릿을 브루트포스하여 계정을 도용하려고 시도할 수 있습니다.
BF에 대한 요청은 다음과 유사할 수 있습니다:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer 헤더 누출 코드 + 상태

클라이언트가 코드와 상태를 가지고 있다면, 다른 페이지로 이동할 때 Referer 헤더에 반영되는지 확인하여 취약점이 있는지 확인할 수 있습니다.

브라우저 기록에 저장된 액세스 토큰

브라우저 기록으로 이동하여 액세스 토큰이 저장되어 있는지 확인합니다.

영구적인 인증 코드

인증 코드는 공격자가 훔쳐서 사용할 수 있는 시간 창을 제한하기 위해 일정 시간 동안만 유지되어야 합니다.

인증/갱신 토큰이 클라이언트에 바인딩되지 않음

인증 코드를 얻고 다른 클라이언트에서 사용할 수 있다면 다른 계정을 탈취할 수 있습니다.

Happy Paths, XSS, Iframes 및 Post Messages를 사용하여 코드 및 상태 값을 누출

이 게시물을 확인하세요

AWS Cognito

이 버그 바운티 보고서에서는 https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/에서 AWS Cognito가 사용자에게 돌려주는 토큰이 사용자 데이터를 덮어쓸 충분한 권한을 가질 수 있다는 것을 확인할 수 있습니다. 따라서, 다른 사용자 이메일로 사용자 이메일을 변경할 수 있다면, 다른 계정을 탈취할 수 있을 수 있습니다.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

AWS cognito를 악용하는 방법에 대한 자세한 정보는 다음을 참조하십시오:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

다른 앱 토큰 악용

이 글에서 언급된대로, 토큰(코드가 아닌)을 기대하는 OAuth 플로우는 토큰이 해당 앱에 속하는지 확인하지 않는 경우 취약할 수 있습니다.

이는 공격자가 OAuth를 지원하는 애플리케이션을 만들고 Facebook으로 로그인 한 다음 피해자가 공격자의 애플리케이션에서 Facebook으로 로그인하면 공격자는 피해자의 OAuth 애플리케이션에 대해 부여된 사용자 토큰을 사용하여 로그인 할 수 있기 때문입니다.

{% hint style="danger" %} 따라서, 공격자가 사용자가 자신의 OAuth 애플리케이션에 액세스하도록 관리하면 토큰이 해당 앱 ID에 부여되었는지 확인하지 않는 애플리케이션에서 피해자의 계정을 탈취할 수 있습니다. {% endhint %}

두 개의 링크 및 쿠키

이 글에서 언급된대로, 피해자가 공격자의 호스트를 가리키는 returnUrl이 포함된 페이지를 열도록 만들 수 있었습니다. 이 정보는 쿠키(RU)에 저장되며 나중에 prompt에서 사용자에게 해당 공격자의 호스트에 대한 액세스를 허용할지 묻습니다.

이 prompt를 우회하기 위해, returnUrl을 사용하여 이 RU 쿠키를 설정하는 Oauth 플로우를 시작하는 탭을 열고, prompt가 표시되기 전에 탭을 닫고 해당 값이 없는 새로운 탭을 열 수 있었습니다. 그러면 prompt는 공격자의 호스트에 대해 알리지 않을 것이지만 쿠키는 해당 호스트로 설정되므로 토큰이 리디렉션에서 공격자의 호스트로 전송됩니다.

SSRF 매개변수

이 연구를 확인하십시오 이 기술에 대한 자세한 내용을 위해.

OAuth의 동적 클라이언트 등록은 서버 측 요청 위조 (SSRF) 공격에 대한 덜 명백하지만 중요한 벡터로 작용합니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부 정보를 수신하도록 허용하며, 이는 악용될 수 있는 민감한 URL을 포함합니다.

주요 포인트:

동적 클라이언트 등록은 일반적으로 /register에 매핑되며, client_name, client_secret, redirect_uris 및 로고 또는 JSON Web Key Sets (JWKs)의 URL과 같은 세부 정보를 POST 요청을 통해 받습니다.
이 기능은 RFC7591 및 OpenID Connect Registration 1.0에서 제시된 사양을 준수하며, SSRF에 취약할 수 있는 매개변수를 포함합니다.
등록 프로세스는 다음과 같은 여러 가지 방법으로 서버를 SSRF에 노출시킬 수 있습니다:
logo_uri: 서버에서 가져올 수 있는 클라이언트 애플리케이션의 로고 URL로, URL이 잘못 처리되면 SSRF를 유발하거나 XSS로 이어질 수 있습니다.
jwks_uri: 클라이언트의 JWK 문서에 대한 URL로, 악의적으로 조작된 경우 서버가 공격자가 제어하는 서버로 외부 요청을 보낼 수 있습니다.
sector_identifier_uri: redirect_uris의 JSON 배열을 참조하며, 서버가 가져올 수 있어 SSRF 기회를 만들 수 있습니다.
request_uris: 클라이언트에 대해 허용된 요청 URI를 나열하며, 서버가 인증 프로세스 시작 시 이러한 URI를 가져오면 악용될 수 있습니다.

악용 전략:

logo_uri, jwks_uri 또는 sector_identifier_uri와 같은 매개변수에 악의적인 URL을 포함하여 새로운 클라이언트를 등록함으로써 SSRF를 트리거할 수 있습니다.
request_uris를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전에 등록된 공격자가 제어하는 request_uri를 제공함으로써 인가 단계 중에 SSRF를 용이하게 할 수 있습니다.

OAuth 공급자의 경쟁 조건

테스트하는 플랫폼이 OAuth 공급자인 경우 가능한 경쟁 조건을 테스트하려면 이를 읽으십시오.

참고 자료