AWS SSO全新PKCE认证机制带来希望（大部分情况下）
2021年，我曾撰文介绍攻击者如何利用AWS SSO设备代码进行钓鱼攻击，使得FIDO认证或身份提供商设备状态等现代安全控制措施失效：通过AWS SSO设备代码认证进行AWS凭证钓鱼。本文将深入分析新发布的AWS SSO认证流程PKCE支持。
设备代码钓鱼简史
- Sebastian Mora撰写了博客文章并发布了"awsssome_phish"，这是一个专为操作设备代码钓鱼攻击而设计的攻击工具
- Chaim Sanders推送文章讨论AWS生态系统中设备代码钓鱼的相关风险
- Matthew Garrett指出设备代码认证有效绕过了近年来实施的许多高级安全机制
- Rami McCarthy发布了详尽的指导文章，概述AWS应采取的潜在措施来解决此问题
- Chris Norman发布了开源浏览器扩展，可以保护用户免受设备代码钓鱼攻击
虽然我没有看到关于实际利用的报告，但至少从两个红队那里直接收到反馈，设备代码钓鱼极其有效。
re:Invent 2024——新希望
在re:Invent前几天，AWS宣布发布“基于PKCE的SSO授权”，该功能现已可用，并在AWS CLI 2.22.0及更高版本中默认启用。虽然PKCE（Proof Key for Code Exchange）这个术语可能听起来晦涩，但它本质上是标准OAuth 2.0授权码流程的实现。
基于PKCE的认证流程的新UI
以下是概念性描述该流程的序列图：
此流程与设备代码认证的根本区别在于，成功认证后，AWS将用户重定向到localhost。在这里，客户端应用程序（本例中为AWS CLI）通过启动临时Web服务器来检索授权码。关键含义是，创建恶意认证链接的攻击者无法检索授权令牌来冒充受害者。即使受害者通过AWS SSO成功认证，他们也将被重定向到localhost并遇到浏览器错误，从而使攻击无效。
这些钓鱼网站从不工作，真是疯狂！
实现细节如何工作？
AWS CLI的实现应该能给你一个很好的理解（更具体地说是SSOTokenFetcherAuth类）。我还复制了一个简单且不太美观的Python实现。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
"""注意：你需要最新版本的boto3。确保替换下面的SSO起始URL。"""
SSO_START_URL='https://d-1234.awsapps.com/start'
import boto3
import jwt
import json
import urllib.parse
import secrets
import base64
import hashlib
def generate_code_verifier_and_challenge():
# 生成加密随机的code_verifier
code_verifier = base64.urlsafe_b64encode(secrets.token_bytes(32)).rstrip(b'=').decode('utf-8')
# 从code_verifier计算code_challenge
digest = hashlib.sha256(code_verifier.encode('utf-8')).digest()
code_challenge = base64.urlsafe_b64encode(digest).rstrip(b'=').decode('utf-8')
return code_verifier, code_challenge
sso_oidc = client = boto3.client('sso-oidc')
redirect_uri = "http://127.0.0.1"
response = client.register_client(
clientName='pkce-demo',
clientType='PUBLIC',
scopes=["sso:account:access"],
redirectUris=[
redirect_uri
],
grantTypes=["authorization_code", "refresh_token"],
)
client_id = response['clientId']
client_secret = response['clientSecret']
code_verifier, code_challenge = generate_code_verifier_and_challenge()
url = "https://oidc.us-east-1.amazonaws.com/authorize?response_type=code"
url += f"&client_id={client_id}"
url += f"&redirect_uri={urllib.parse.quote(redirect_uri)}"
url += "&state=dontcare"
url += "&code_challenge_method=S256"
url += "&scopes=sso%3Aaccount%3Aaccess"
url += f"&code_challenge={code_challenge}"
# 在不验证签名的情况下解码client_secret中的JWT
claims = jwt.decode(client_secret, options={"verify_signature": False})
# 交互式读取令牌
print("请在浏览器中打开此URL：")
print(url)
print()
print("当您被重定向到localhost时，请粘贴下面的OAuth代码：")
code = input("OAuth代码: ")
response = client.create_token(
grantType='authorization_code',
clientId=client_id,
clientSecret=client_secret,
redirectUri=redirect_uri,
codeVerifier=code_verifier,
code=code
)
access_token = response['accessToken']
print("成功检索到AWS SSO访问令牌。")
print("可用的AWS账户：")
sso_client = boto3.client('sso')
response = sso_client.list_accounts(accessToken=access_token)
for account in response.get('accountList', []):
print(f" - {account['accountName']} ({account['accountId']})")
"""
现在生成一些凭据！
response = sso_client.get_role_credentials(
roleName='account-admin',
accountId='111111',
accessToken=access_token
)
print(response)
"""
|
示例输出：
1
2
3
4
5
6
7
8
9
|
请在浏览器中打开此URL：
https://oidc.us-east-1.amazonaws.com/authorize?response_type=code&client_id=icBsllQ8y8kJWfyMjKH3cnVzLWVhc3QtMQ&redirect_uri=http%3A//127.0.0.1&state=dontcare&code_challenge_method=S256&scopes=sso%3Aaccount%3Aaccess&code_challenge=wJYlfWmU3ejXGVbUbiXhahQHUaexSrlcLSQahygGCkk
当您被重定向到localhost时，请粘贴下面的OAuth代码：
OAuth代码: eyJr...TB2d5pEmNPNJ6GMNypXkAr
成功检索到AWS SSO访问令牌。
可用的AWS账户：
- Sandbox (12345678901)
- Honeypots (1111111111)
|
攻击者能否使用恶意重定向URL窃取授权令牌？
OAuth实现中最常见的漏洞之一是允许攻击者制作重定向到攻击者控制域的恶意认证URL。成功时，这允许攻击者拦截授权令牌并冒充受害者。
在这种情况下，AWS通过将重定向URL限制为localhost来减轻此风险。此限制确保由AWS CLI启动的临时Web服务器是授权码的唯一接收者。我尝试使用各种技术绕过此验证，包括嵌入IPv4组件的IPv6地址和DNS重绑定。然而，所有尝试都未成功——这是一个好迹象，表明实现是健壮的（或者我是个糟糕的渗透测试员）。
这真的不能用于钓鱼目的吗？
绝对不能——至少在设计上不能，不像设备代码认证那样天生容易受到钓鱼攻击。唯一潜在的风险是如果AWS的实现存在漏洞，例如攻击者能够绕过重定向URL允许列表。如果你是熟练的应用安全人员，我鼓励你尝试一下：这将是一个很好的提交到AWS在HackerOne上的新VDP程序！
那么…我们安全了吗？
不幸的是，尽管基于PKCE的认证是正确的方向，但设备代码认证仍然可用，并且无法禁用它。因此，这个新版本并没有关闭它本应缓解的攻击向量。
AWS以其对向后兼容性的坚定承诺而闻名，可能提前发布此功能以推动采用并逐步扩展，并可能计划允许组织在未来强制执行基于PKCE的认证。
你应该做什么？
- 将AWS CLI升级到最新版本（2.22.0+），默认使用基于PKCE的流程（注意：aws-vault中的支持即将到来）
- 鼓励组织中的每个人过渡到基于PKCE的流程
- 使用CloudTrail检测和警报旧设备代码流程的使用。您可以通过匹配具有以下属性的CloudTrail日志来创建警报：
- eventName = CreateToken
- eventSource = sso.amazonaws.com
- requestParameters.grantType = urn:ietf:params:oauth:grant-type:device_code
如果你有EDR或代理的访问权限，你还可以在网络级别阻止device.sso..amazonaws.com。这将确保没有人可以从企业设备使用设备代码认证。
如果设备代码钓鱼对你来说是个问题，请告知你的AWS TAM，以便他们在内部进行倡导。
感谢阅读！你可以在LinkedIn和Bluesky上找到我。
参考资料