故意泄漏AWS密钥

2021-01-20 02:23:53

“永远不要将秘密检查到源代码管理中”是100%正确的规则之一,直到不正确为止。软件中没有通用的法律,最近我有理由打破这一法律。我将AWS密钥签入了Git存储库。 Ithen将这些提交推送到GitHub上的公共存储库中。我故意这样做,并且活着讲述这个故事。您几乎肯定不应该这样做,所以我想我会分享您这样做时的情况。

我可以想象您在想:“这个人是故意发布他的AWS凭证的?一定是个白痴。”我不同意您的结论,但请让我解释一下!

我的用例非常简单:delta-rs项目需要一个真正的S3bucket来进行一些集成测试。我决定建立一个真正的S3存储桶forour(只读)集成测试。幸运的是,我们的测试仅需要从存储桶中检索对象,以确认S3存储桶正确地将自己呈现为Delta表。如果我们需要在存储桶上进行“写入”操作,我将永远不会这样做。

AWS有一个称为IAM的集成访问控制框架,不要与“ AMI”字谜相混淆,Corey Quinn可以帮助您学习如何发音。 IAM允许以十几种或更多不同的方式针对AWS中的所有内容制定策略和角色。它切成薄片,确保您的水桶安全。它还配置了JSON,该功能非常实用,但是我必须将这些保留的内容保存在另一篇博客文章中。无论如何,这是我为存储桶设置的只读策略:

{"版本" :" 2012-10-17" ,"声明" :[{" Sid" :" VisualEditor0" ,"效果" :"允许" ,"动作" :[" s3:GetLifecycleConfiguration" ," s3:GetBucketTagging" ," s3:GetInventoryConfiguration" ," s3:GetObjectVersionTagging" ," s3:ListBucketVersions" ," s3:GetBucketLogging" ," s3:ListBucket" ," s3:GetAccelerateConfiguration" ," s3:GetBucketPolicy" ," s3:GetObjectVersionTorrent" ," s3:GetObjectAcl" ," s3:GetEncryptionConfiguration" ," s3:GetBucketObjectLockConfiguration" ," s3:GetBucketRequestPayment" ," s3:GetObjectVersionAcl" ," s3:GetObjectTagging" ," s3:GetMetricsConfiguration" ," s3:GetBucketOwnershipControls" ," s3:GetBucketPublicAccessBlock" ," s3:GetBucketPolicyStatus" ," s3:ListBucketMultipartUploads" ," s3:GetObjectRetention" ," s3:GetBucketWebsite" ," s3:GetBucketVersioning" ," s3:GetBucketAcl" ," s3:GetObjectLegalHold" ," s3:GetBucketNotification" ," s3:GetReplicationConfiguration" ," s3:ListMultipartUploadParts" ," s3:GetObject" ," s3:GetObjectTorrent" ," s3:GetBucketCORS" ," s3:GetAnalyticsConfiguration" ," s3:GetObjectVersionForReplication" ," s3:GetBucketLocation" ," s3:GetObjectVersion" ],"资源" :[" arn:aws:s3 ::: deltars" ," arn:aws:s3 ::: deltars / *" ]}]}

我还设置了一个AWSBudget来提醒网购此举是否会花掉真钱。我当前在该AWS账户中的每月费用几乎为1.50美元,因此我的预算设置为,如果/当此开始每月花费我数美元以上时,AWS会向我发送电子邮件,以便我想出办法来节省我的钱钱。

最后,我为集成测试创建了一个IAM用户。此IAM用户已附加上面列出的单个IAM策略。然后,我获取了IAM用户的AWS访问密钥和私钥ID,并将其签入Git。

准备完集成测试后,我在太平洋标准时间13:05提出了我的pullrequest。在将代码推送到GitHub时,世界上的机器人会立即识别出任何类似于AWS访问密钥的东西,其中大多数意图是恶意的,但有些旨在帮助像我这样的开发人员犯下愚蠢的错误。

我们已经知道,属于IAM用户deltars-ro的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH以及相应的密钥在以下网址在线公开可用:https://github.com/rtyler/delta.rs/blob/b3581ee06eee26d971bd3b76bb788c85ecf0c6c0c/rust/ tests / s3_test.rs。

您的安全性对我们很重要,并且您帐户的IAM凭证的暴露给您的AWS帐户带来安全风险,可能导致未经授权的活动产生过多费用,并违反AWS客户协议或与我们有关管理您对我们服务使用的其他协议。

为了保护您的帐户免遭过多的费用和未经授权的活动,我们已将“ AWSCompromisedKeyQuarantine” AWS托管策略(“隔离策略”)应用于上述IAM用户。应用于用户的隔离策略通过限制高风险AWS服务的权限来保护您的账户。您可以通过以下网址查看该策略:https://console.aws.amazon.com/iam/home#policies/arn:aws: iam :: aws:policy / AWSCompromisedKeyQuarantine $ jsonEditor?section = permissions。

为了安全起见,在遵循以下说明之前,请勿删除隔离策略。如果隔离策略导致生产问题,则可以将策略与用户分离。注意:只有具有管理员权限或有权访问iam:DetachUserPolicy的用户才能删除该策略。有关如何删除托管策略的说明,请访问:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#remove-policies-console。如果未经授权使用您的AWS账户,我们可以全权酌情为您提供让步。但是,不遵循以下说明可能会损害您获得让步的能力。

如果您认为自己收到的此说明有误,请立即通过支持案例与我们联系。

步骤1:删除或旋转公开的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH。要删除IAM用户密钥,请转到此处的AWS管理控制台:https://console.aws.amazon.com/iam/home#users。要删除根用户密钥,请访问:https://console.aws.amazon.com/iam/home#security_credential。

如果您的应用程序使用公开的访问密钥,则需要更换密钥。要替换密钥,请先创建第二个密钥(届时两个密钥都将处于活动状态),然后修改您的应用程序以使用新密钥。然后,通过单击“使无效”来禁用(但不要删除)公开的密钥。控制台中的选项。如果您的应用程序有任何问题,您可以重新激活公开的密钥。当您的应用程序使用新密钥完全正常运行时,请删除公开的密钥。

注意:仅旋转或删除外露的钥匙可能不足以保护您的帐户,请参阅步骤2。

步骤2:检查您的CloudTrail日志中是否存在未经批准的活动,例如创建未经授权的IAM用户,策略,角色或临时安全凭证。为了保护您的帐户,请删除所有未经授权的IAM用户,角色和策略,并撤消所有临时凭据。

要删除未经授权的IAM用户,请导航至https://console.aws.amazon.com/iam/home#users。要删除未经授权的策略,请访问:https://console.aws.amazon.com/iam/home#/policies。要删除未经授权的角色,请访问:https://console.aws.amazon.com/iam/home#/roles。

可能已使用公开的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH为IAM用户deltars-ro创建了未经授权的临时凭证。您可以按照此处概述的说明撤消临时凭证:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html#denying-access-to-credentials-issue-time 。也可以通过删除IAM用户来撤销临时凭据。注意:删除IAM用户可能会影响生产工作负载,因此应谨慎进行。

步骤3:检查CloudTrail日志以查看您的AWS账户是否有未经授权的AWS使用,例如未经授权的EC2实例,Lambda函数或EC2竞标价。您还可以通过登录AWS管理控制台并查看每个服务页面来检查使用情况。还可以检查计费控制台中的“计费”页面,以防意外使用。 https://console.aws.amazon.com/billing/home#/bill

请记住,任何区域都可能发生未经授权的使用,并且您的控制台一次只能向您显示一个区域。要在区域之间切换,可以使用控制台屏幕右上角的下拉菜单。

请采取措施以防止任何新的凭据公开暴露。请参阅http://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html上的“管理访问密钥的最佳做法”。

Amazon GuardDuty是一项AWS威胁检测服务,可帮助您持续监控和保护您的AWS账户和工作负载。在您的账户上启用Amazon GuardDuty可以使您进一步了解恶意或未经授权的活动,提醒您采取措施以减少受到伤害的风险。要了解更多信息,请访问:https://aws.amazon.com/guardduty。

如果您有任何疑问,可以通过访问帐户支持中心中新创建的支持案例与我们联系。如果看不到新案例,则可以从以下支持中心创建案例:https://console.aws.amazon.com/support/home?#/

我还在太平洋标准时间13:09收到了来自两个第三方服务GitGuardian的电子邮件,而太平洋标准时间14:56也收到了泄漏.io的电子邮件。伙计们,可以尝试一下,但是在我执行git push的几秒钟内,AWS已经在它之上。

我忽略了第三方服务,并回复了AWS支持案例,让他们知道我的披露实际上是故意的。支持人员一定会翻过双眼,然后提醒我负责该帐户的收费,但仍建议我:

通常这个故事结局不好。我是有目的地并按计划进行的。我个人知道(我的一个朋友的朋友!)GitHub上有泄露AWS密钥的事件(我发誓!)。发生错误的git将本地凭证文件添加到个人但公共存储库中。由于未定期检查链接到AWS账户的电子邮件账户,因此在撤销密钥之前,滥用该密钥在AWS账单上累积了数百美元。

如果您将类似于AWS密钥的内容添加到公共存储库,网站或互联网上的任何内容,恶意参与者将下载密钥并尝试在您的AWS账户中启动服务。通常是加密货币矿工或垃圾邮件网关,任何花费大量金钱的东西,他们很高兴您自愿支付。