AWS SSO新型PKCE认证带来希望（大部分情况下）

2021年，我曾撰文介绍攻击者如何利用AWS SSO设备代码进行钓鱼攻击，使得FIDO认证或身份提供商设备状态检查等现代安全控制措施失效。本文我们将深入探讨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的认证流程新界面

以下是概念性描述该流程的序列图：

此流程与设备代码认证的根本区别在于，成功认证后，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


"""注意：您需要较新版本的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']})")

示例输出：

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。这将确保没有人可以从公司设备使用设备代码认证。