文章总结： AWS新功能awslogin–remote存在钓鱼风险，攻击者可通过恶意网站诱导用户提供验证码获取临时凭证。文章详细解释了攻击流程，提供了预防措施(禁用signin:AuthorizeOAuth2Access和signin:CreateOAuth2Token权限)和检测方法(监控CloudTrail事件中的CreateOAuth2Token和AuthorizeOAuth2Access操作)。建议用户不要将验证码输入不受信任的网站。
综合评分： 89
文章分类： 云安全,威胁情报,漏洞分析,安全意识,社会工程学
AWS新功能“aws login”潜藏的钓鱼风险剖析
Dubito
云原生安全指北
2025年12月5日 08:35
江苏
注：本文翻译自Medium – Adan[1]的文章《Phishing for AWS Credentials via the New ‘aws login’ Flow》[2]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
在阅读 “pre:Invent” 季发布的新 AWS 功能时，我注意到了新的 aws login 命令。这让我立刻想起了 Christophe Tafani-Dereeper 那篇精彩的博客文章：《通过 AWS SSO 设备码验证进行 AWS 凭证钓鱼[3]》。
为什么会联想到这个？
因为新的 aws login 命令同样可能被攻击者滥用于钓鱼攻击。虽然它不像 AWS SSO 设备码攻击那么简单直接（需要更多的用户交互），但这仍然是一个值得关注的问题。它可以绕过防钓鱼的多因素认证（MFA），并可能被用于对root凭证进行钓鱼。因此，我认为有必要提高对此的认识。
免责声明： 这 并非 AWS 或
aws login功能本身的安全漏洞。这种攻击依赖于用户主动将敏感程度等同于 AWS 凭证的验证码提供给攻击者。
二、什么是 ‘aws login’？
aws login 是一个新的 AWS 命令行界面（CLI）命令，允许开发者为本地开发获取临时凭证。如果您想了解完整的官方说明，可以阅读 AWS 发布博客[4]。
三、’aws login’ 如何获取凭证？
aws login 命令使用了带有 PKCE 的 OAuth 2.0 授权码流程。在常规场景下，其工作流程如下：
- 1. 用户运行
aws login。 - 2. AWS CLI 会打开一个浏览器，并加载一个包含 OAuth 详细信息的生成好的 URL。
- 3. AWS 允许用户使用现有会话，或以root用户或 IAM 用户身份登录。
- 4. 用户选择会话或完成登录。
- 5. AWS 将用户重定向回 AWS CLI，并附带一个授权码。
- 6. CLI 将该授权码交换为临时凭证。
这是正常的方法。
AWS 还提供了另一种选项。这是为没有浏览器的远程服务器设计的。其流程如下：
- 1. 用户运行
aws login --remote。 - 2. AWS CLI 会打印一个可在另一台设备上打开的 URL。
- 3. 用户在浏览器中打开该 URL。
- 4. AWS 允许用户使用现有会话或进行登录。
- 5. 用户选择会话或完成登录。
- 6. AWS 显示一个可用于交换凭证的验证码。
- 7. 用户将验证码复制回远程运行的 CLI 中。
- 8. CLI 将该验证码发送给 AWS。
- 9. AWS 返回临时凭证。
图 1. aws login —remote 流程图
这种方法为钓鱼攻击创造了机会，因为浏览器和 CLI 是完全分离的。界面上的文字也对此发出了警告：“仅将验证码提供给您发起 aws login 进程的地方，或者您信任的可以访问您 AWS 账户资源的应用程序。” 以及 “将唯一的验证码复制到您的开发者工具中。AWS 绝不会通过电子邮件、电话或聊天向您索要此验证码。”
图 2. AWS 返回验证码时显示的警告文本
四、攻击者如何滥用 ‘aws login –remote’
关键在于，请求凭证的 CLI 进程与浏览器会话之间没有任何关联。这是设计使然，因为远程服务器无法打开浏览器。
但请想象一下，如果远程服务器被攻击者控制了会怎样。
攻击者的目标很简单：诱使受害者打开一个由 aws login --remote CLI 生成的真实 AWS 登录页面 URL，然后让受害者将 AWS 显示的验证码交给攻击者（因为我们知道，并非每个人都会停下来阅读所有内容）。即使受害者使用了防钓鱼的多因素认证（MFA），这种方法依然有效，因为受害者完成的是一个正常的 AWS 登录流程。
一个可能的攻击流程如下：
- 1. 受害者访问一个恶意网站。
- 2. 恶意网站在后台运行
aws login --remote。 - 3. AWS CLI 返回一个真实的 AWS URL。
- 4. 恶意网站指示受害者打开该 URL 以“验证其 AWS 会话”。
- 5. 受害者打开了真实的 AWS 登录页面。
- 6. AWS 要求受害者使用现有会话或登录。
- 7. 受害者完成登录或选择其会话。
- 8. AWS 向受害者显示一个验证码。
- 9. 受害者将该验证码输入到恶意网站上。
-
- 恶意网站将该验证码传递给它自己的 CLI 进程。
-
- CLI 将该验证码与 AWS 进行交换。
-
- AWS 返回临时凭证，现在这些凭证已属于攻击者。
至此，攻击者可以在临时凭证过期前，任意使用受害者的 AWS 访问权限。
图 3. 使用 aws login –remote 的潜在恶意流程示意图
我创建了一个包含虚假网站的小型演示，以展示这在真实场景中可能呈现的样子：
图 4. 模拟验证码钓鱼网站的演示
五、预防与检测
5.1 预防措施
好消息是，这种钓鱼方法可以通过策略来阻止。
aws login 功能需要两个 IAM 权限：
- •
signin:AuthorizeOAuth2Access - •
signin:CreateOAuth2Token
如果您正在使用 AWS Identity Center，并且不需要这项新功能，可以禁用这些权限。以下是一个实现此功能的 SCP 示例：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOAuth2AuthorizationAndTokenCreation",
"Effect": "Deny",
"Action": ["signin:AuthorizeOAuth2Access", "signin:CreateOAuth2Token"],
"Resource": "*"
}
]
}
您也可以自定义 SCP，仅允许从您信任的网络发起这些操作。
5.2 检测方法
如果您允许使用 aws login，仍然可以检测可疑活动。CloudTrail 会记录两个操作：CreateOAuth2Token 和 AuthorizeOAuth2Access。以下是事件示例：
CreateOAuth2Token：当用户请求令牌时记录。
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAXXXXXXXXXXXXXXXX:USER_1",
"arn": "arn:aws:sts::123456789012:assumed-role/ROLE_1/USER_1",
"accountId": "123456789012",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAXXXXXXXXXXXXXXXX",
"arn": "arn:aws:iam::123456789012:role/ROLE_1",
"accountId": "123456789012",
"userName": "ROLE_1"
},
"attributes": {
"creationDate": "2025-11-22T20:29:41Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2025-11-22T21:02:26Z",
"eventSource": "signin.amazonaws.com",
"eventName": "CreateOAuth2Token",
"awsRegion": "us-west-2",
"sourceIPAddress": "0.0.0.0",
"userAgent": "USER_AGENT_REDACTED",
"requestParameters": {
"client_id": "CLIENT_ID_REDACTED"
},
"responseElements": null,
"additionalEventData": {
"success": "true",
"x-amzn-vpce-id": ""
},
"requestID": "REQUEST_ID_REDACTED",
"eventID": "EVENT_ID_REDACTED",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-west-2.signin.aws.amazon.com"
}
}
AuthorizeOAuth2Access：当 CLI 进行令牌交换时记录。
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAXXXXXXXXXXXXXXXX:USER_1",
"arn": "arn:aws:sts::123456789012:assumed-role/ROLE_1/USER_1",
"accountId": "123456789012",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAXXXXXXXXXXXXXXXX",
"arn": "arn:aws:iam::123456789012:role/ROLE_1",
"accountId": "123456789012",
"userName": "ROLE_1"
},
"attributes": {
"creationDate": "2025-11-22T20:29:41Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2025-11-22T21:07:22Z",
"eventSource": "signin.amazonaws.com",
"eventName": "AuthorizeOAuth2Access",
"awsRegion": "us-west-2",
"sourceIPAddress": "0.0.0.0",
"userAgent": "USER_AGENT_REDACTED",
"requestParameters": {
"scope": "openid",
"redirect_uri": "https://us-west-2.signin.aws.amazon.com/v1/sessions/confirmation",
"code_challenge_method": "SHA-256",
"client_id": "arn:aws:signin:::devtools/cross-device"
},
"responseElements": null,
"additionalEventData": {
"success": "true",
"x-amzn-vpce-id": ""
},
"requestID": "REQUEST_ID_REDACTED",
"eventID": "EVENT_ID_REDACTED",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-west-2.signin.aws.amazon.com"
}
}
以下两种检测策略可能有用：
检查 client_id 值： 当使用 --remote 参数时，requestParameters.client_id 的值为：arn:aws:signin:::devtools/cross-device
查找不同的 IP 地址： 在钓鱼场景中，受害者从 IP 地址 A 登录，而攻击者从 IP 地址 B 交换验证码。这种不匹配是一个明显的钓鱼指标。在真实的远程使用场景中也可能发生这种情况，但这仍然对检测很有价值。
六、结论
这就是为什么我们无法拥有完美无瑕的好东西。AWS 发布任何有用的功能时，像我这样的安全人士立刻会问：“太好了……但这东西可能被如何滥用呢？”
尽管有这种考虑，aws login 仍然是一个非常优秀且受欢迎的功能。它有助于减少长期访问密钥（long-lived access keys）的创建，而这仍然是 AWS 环境中最常见的安全问题之一。迈向短期、自动刷新的凭证对所有人来说都是正确的方向。
如果您已经在使用 AWS Identity Center，那么您实际上并不太需要这个新方法，因为获取临时凭证已经非常简单和安全。所以，如果您不打算使用 aws login，尽管阻止它好了。尽管由于需要用户交互，其社会工程学风险较低，但这仍然是您可以完全消除的一个风险。
如果您计划使用它，请密切关注 CloudTrail 事件，理解登录流程的工作原理，并提醒用户永远不要将 AWS 登录验证码输入到不受信任的网站，或通过任何方式分享它们。
顺便提一下，我最近在A2SECURE[5] 开始了新的职位。您可以在此 阅读[6] 我关于 AWS pre:Invent 2025 的第一篇文章。
引用链接
[1] Adan: https://medium.com/@adan.alvarez
[2] 《Phishing for AWS Credentials via the New ‘aws login’ Flow》: https://medium.com/@adan.alvarez/phishing-for-aws-credentials-via-the-new-aws-login-flow-39f6969b4eae
[3] 通过 AWS SSO 设备码验证进行 AWS 凭证钓鱼: https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/
[4] AWS 发布博客: https://aws.amazon.com/es/blogs/security/simplified-developer-access-to-aws-with-aws-login/
[5] A2SECURE: https://www.a2secure.com/
[6] 阅读: https://www.a2secure.com/en/blog-en-2/aws-preinvent-security-highlights-what-changed-impact/
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito《AWS新功能“aws login”潜藏的钓鱼风险剖析》