Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

14 KiB
Raw Blame History

OAuth到账户接管

从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS红队专家）！

支持HackTricks的其他方式：

基本信息

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流程如下进行：

  1. 您访问https://example.com并选择“与社交媒体集成”按钮。
  2. 网站随后向https://socialmedia.com发送请求，请求您授权让https://example.com的应用程序访问您的帖子。请求结构如下：
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

  1. 然后会显示一个同意页面。

  2. 在您批准后，社交媒体会向 redirect_uri 发送带有 code 和 state 参数的响应：

https://example.com?code=uniqueCode123&state=randomString123
  1. 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"}
  1. 最后，过程在 https://example.com 使用您的 access_token 发起 API 调用到社交媒体以获取访问权限。

漏洞

开放式 redirect_uri

redirect_uri 在 OAuth 和 OpenID 实现中至关重要，因为它指示授权后发送敏感数据（如授权码）的位置。如果配置错误，可能会允许攻击者将这些请求重定向到恶意服务器，从而实现接管账户。

利用技术因授权服务器的验证逻辑而异。它们可以从严格的路径匹配到接受指定域或子目录内的任何 URL。常见的利用方法包括开放式重定向、路径遍历、利用弱正则表达式和 HTML 注入以窃取令牌。

除了 redirect_uri 外，其他 OAuth 和 OpenID 参数，如 client_uri、policy_uri、tos_uri 和 initiate_login_uri 也容易受到重定向攻击。这些参数是可选的，它们的支持在不同服务器之间有所不同。

对于针对 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 - Improper handling of state parameter

在OAuth实现中，state参数的错误使用或省略会显著增加**跨站请求伪造（CSRF）**攻击的风险。当state参数未被使用、被用作静态值或未经适当验证时，就会出现这种漏洞，使攻击者能够绕过CSRF保护。

攻击者可以通过拦截授权过程将其账户与受害者的账户关联起来，从而导致潜在的账户接管。这在OAuth用于身份验证目的的应用程序中尤为关键。

这种漏洞的实际案例已在各种CTF挑战和黑客平台中有所记录，突显了其实际影响。该问题还涉及与Slack、Stripe和PayPal等第三方服务的集成，攻击者可以将通知或付款重定向到其账户。

对**state参数**的正确处理和验证对于防范CSRF攻击并保护OAuth流程至关重要。

Pre Account Takeover

  1. 在账户创建时未进行电子邮件验证：攻击者可以预先使用受害者的电子邮件创建一个账户。如果受害者后来使用第三方服务进行登录，应用程序可能会无意中将这个第三方账户与攻击者预先创建的账户关联起来，导致未经授权的访问。

  2. 利用OAuth宽松的电子邮件验证：攻击者可能会利用不验证电子邮件的OAuth服务，通过注册其服务然后更改账户电子邮件为受害者的电子邮件来实施攻击。这种方法类似于第一个场景，但通过不同的攻击向量同样存在未经授权的账户访问风险。

揭示秘密

识别和保护秘密的OAuth参数至关重要。虽然**client_id可以安全地公开，但揭示client_secret会带来重大风险。如果client_secret泄露，攻击者可以利用应用程序的身份和信任来窃取用户的access_tokens**和私人信息。

当应用程序错误地在客户端而不是服务器端处理授权code以获取access_token时，就会出现常见的漏洞。这个错误导致client_secret的暴露，使攻击者能够在应用程序的名义下生成access_tokens。此外，通过社会工程，攻击者可以通过向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 Header leaking Code + State

一旦客户端获得了code和state，如果在他浏览到不同页面时在Referer标头中反映出来，那么就存在漏洞。

Access Token Stored in Browser History

前往浏览器历史记录并检查访问令牌是否保存在其中。

Everlasting Authorization Code

授权码应该只存在一段时间，以限制攻击者可以窃取和使用它的时间窗口。

Authorization/Refresh Token not bound to client

如果你可以获得授权码并将其与不同的客户端一起使用，那么你可以接管其他账户。

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

查看此文章

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"
}
]
}

滥用其他应用程序的令牌

正如在这篇文章中提到的，期望接收令牌（而不是代码）的OAuth流程可能存在漏洞，如果它们不检查令牌是否属于该应用程序。

这是因为攻击者可以创建一个支持OAuth并使用Facebook登录（例如）的应用程序。然后，一旦受害者在攻击者的应用程序中使用Facebook登录，攻击者就可以获取用户授予其应用程序的OAuth令牌，并使用该令牌登录受害者OAuth应用程序中的受害者用户。

{% hint style="danger" %} 因此，如果攻击者成功让用户访问自己的OAuth应用程序，他将能够接管期望令牌的应用程序中受害者的帐户，并且这些应用程序没有检查令牌是否授予其应用程序ID。 {% endhint %}

两个链接和cookie

根据这篇文章，可以让受害者打开一个带有指向攻击者主机的returnUrl的页面。这些信息将被存储在一个cookie（RU）中，在后续步骤中，提示将询问用户是否愿意授予该攻击者主机访问权限。

为了绕过此提示，可以打开一个选项卡来启动Oauth流程，该流程将使用returnUrl设置此RU cookie，然后在显示提示之前关闭选项卡，并打开一个不包含该值的新选项卡。然后，提示不会提及攻击者的主机，但cookie将被设置为该主机，因此令牌将被发送到攻击者的主机进行重定向。

SSRF参数

查看此研究 以获取有关此技术的更多详细信息。

OAuth中的动态客户端注册作为安全漏洞的一个不太明显但关键的向量，特别是用于**服务器端请求伪造（SSRF）**攻击。此端点允许OAuth服务器接收有关客户端应用程序的详细信息，包括可能被利用的敏感URL。

关键要点：

  • 动态客户端注册通常映射到/register，通过POST请求接受诸如client_name、client_secret、redirect_uris和用于logo或JSON Web Key Sets（JWKs）的URL等详细信息。
  • 此功能遵循RFC7591和OpenID Connect Registration 1.0中规定的规范，其中包括可能容易受到SSRF攻击的参数。
  • 注册过程可能会以几种方式无意中使服务器暴露于SSRF的风险中：
    • logo_uri：客户端应用程序的logo的URL，服务器可能会获取该URL，触发SSRF或如果URL处理不当可能导致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。