1. 项目概述当渗透测试遇上云存储在当前的渗透测试实战中云环境已经从一个“加分项”变成了“必选项”。尤其是AWS作为市场份额最大的云服务提供商其庞大的生态和复杂的配置常常成为安全评估中的关键战场。这次我们要聊的就是其中一个非常经典且高风险的场景扫描并连接AWS环境进而利用配置不当的S3存储桶。这听起来可能有点技术化但简单来说它就像是你在一次安全评估中发现目标公司把一些敏感文件比如客户数据、内部代码、配置文件放在了一个“云上保险柜”里但这个保险柜的门没锁好甚至钥匙就挂在门上。我遇到过不少案例从初创公司到大型企业都曾在这个环节栽过跟头。S3存储桶的配置错误比如公开读写权限public-read-write、错误的桶策略Bucket Policy或访问控制列表ACL往往不是开发人员有意为之而是在追求开发效率时无意中留下的“后门”。对于渗透测试人员而言这不仅仅是一个技术点更是一个需要系统性思维的过程如何从外部视角发现AWS资产如何验证其归属如何精准定位到有问题的S3桶以及在发现漏洞后如何规范地验证、利用并评估风险这个过程远比运行一个扫描器要复杂得多。2. 核心思路与前期侦察策略2.1 从“无头苍蝇”到“有的放矢”的侦察转变很多新手在拿到一个目标时可能会直接祭出Nmap进行全端口扫描或者用dirsearch狂扫目录。但在云渗透的语境下尤其是针对AWS这种“地毯式轰炸”效率极低且容易触发警报。我们的核心思路必须转变从IP和端口的侦察转向对云服务元数据、域名解析记录和公开信息的搜集。目标不是找到一台服务器的开放22端口而是找到属于目标公司的AWS资源标识符比如S3桶名、CloudFront发行版ID、或是AWS账户ID的蛛丝马迹。为什么这么强调因为云服务是高度抽象化的。一个S3桶背后可能没有你传统认知中的“服务器IP”它通过一个全球唯一的端点如bucket-name.s3.amazonaws.com提供服务。我们的攻击面从IP变成了这些服务端点、API接口和配置策略。2.2 开源情报OSINT搜集实战这是整个流程的基石大约70%的成功案例都始于有效的OSINT。你需要像个侦探一样从公开信息中拼凑线索。域名与子域名枚举这是发现S3桶名的首要途径。使用像amass、subfinder、assetfinder这样的工具进行子域名爆破。但关键不在于数量而在于模式。你要特别关注那些看起来像S3端点的子域名常见模式有s3.amazonaws.com后缀assets.s3.amazonaws.com区域端点bucket-name.s3-us-west-2.amazonaws.coms3-website端点bucket-name.s3-website-us-east-1.amazonaws.com这通常意味着桶被配置为静态网站托管虚拟托管样式bucket-name.s3.amazonaws.com或直接是bucket-name如果CNAME指向S3 一个高效的技巧是在获取子域名列表后用grep过滤包含s3、storage、assets、media、backup等关键词的条目。DNS记录深度挖掘除了A记录更要关注CNAME记录。很多公司会将cdn.example.com或static.example.com的CNAME指向CloudFront或S3的端点。使用dig或在线DNS查询工具仔细查看目标域名的所有DNS记录类型。代码仓库与历史泄露在GitHub、GitLab、Bitbucket上搜索目标公司的代码仓库。开发者经常在配置文件如.env、config.json、serverless.yml、基础设施即代码IaC文件如terraform.tfvars、cloudformation.yaml中硬编码AWS访问密钥、S3桶名甚至密钥。使用高级搜索语法例如org:companyname “s3://”或“AKIA”AWS访问密钥ID的前缀。SSL/TLS证书分析通过证书透明度CT日志可以发现为目标域名签发的所有证书。工具如crt.sh或certspotter能帮你找到关联子域名其中可能包含云资源端点。注意OSINT阶段务必做好信息关联和去重。将发现的所有疑似AWS资源端点、桶名、账户ID片段整理到一个结构化的笔记中这是后续所有动作的输入源。3. 工具选型与自动化扫描框架搭建手动搜集效率低下我们需要一套半自动化的流程。工具的选择不在于多而在于精和组合使用。3.1 核心工具链解析子域名枚举amass以其强大的数据源和递归枚举能力成为首选。subfinder则速度更快适合初步扫描。我通常的流程是subfinder -d example.com -silent | tee subs.txt快速获取列表再用amass enum -passive -d example.com进行深度补充。S3桶名爆破与验证这是关键一步。仅仅发现一个可能的桶名如dev-example-assets还不够需要验证它是否存在且可访问。这里强烈推荐s3scanner或cloud_enum。s3scanner专为S3设计速度快能识别桶的存在性、区域和权限状态公开读、公开写、可列清单。cloud_enum功能更全面支持多云AWS、Azure、GCP不仅能找S3桶还能找Azure存储容器、Google Cloud存储桶等。 使用方式示例python3 cloud_enum.py -k example -k companyname -l。这里的-k参数是你搜集到的关键词工具会基于这些关键词生成大量可能的桶名进行测试。权限检查与内容列举当确认一个桶存在后你需要知道能对它做什么。AWS CLI 是终极武器但前提是你有权限。对于公开桶可以直接使用。更通用的方法是使用像aws-s3-bucket-scanner这类工具或者自己写简单的Python脚本利用boto3库AWS SDK for Python进行交互。 一个基础但至关重要的检查清单ListObjects能否列出桶内所有文件命令aws s3 ls s3://bucket-name/ --no-sign-request--no-sign-request参数表示使用匿名访问不提供密钥。GetObject能否下载特定文件命令aws s3 cp s3://bucket-name/secret-file.txt ./ --no-sign-request。PutObject能否上传文件高危操作渗透测试中需极度谨慎必须有明确授权命令aws s3 cp ./test.txt s3://bucket-name/ --no-sign-request。Bucket Policy / ACL能否获取桶的策略这通常需要认证但有时配置错误会导致策略信息泄露。3.2 搭建你的自动化侦察流水线我习惯将这个过程脚本化形成一个流水线。下面是一个简化版的Shell脚本思路你可以基于此扩展#!/bin/bash TARGETexample.com OUTPUT_DIR./scans/$TARGET-$(date %Y%m%d) mkdir -p $OUTPUT_DIR echo [*] 开始子域名枚举... subfinder -d $TARGET -silent -o $OUTPUT_DIR/subfinder.txt amass enum -passive -d $TARGET -o $OUTPUT_DIR/amass.txt cat $OUTPUT_DIR/*.txt | sort -u $OUTPUT_DIR/all_subs.txt echo [*] 提取潜在S3相关域名... grep -i s3\|storage\|assets\|bucket\|cdn $OUTPUT_DIR/all_subs.txt $OUTPUT_DIR/s3_candidates.txt echo [*] 使用 cloud_enum 进行桶名爆破... # 从目标域名中提取关键词例如 ‘example, ‘company KEYWORDS$(echo $TARGET | tr . \n | head -n1) python3 /tools/cloud_enum/cloud_enum.py -k $KEYWORDS -k $TARGET -l -o $OUTPUT_DIR/cloud_enum.txt echo [*] 验证桶的公开访问权限... for bucket in $(cat $OUTPUT_DIR/cloud_enum.txt | grep -i s3 | cut -d -f2); do echo 检查 $bucket ... aws s3 ls s3://$bucket/ --no-sign-request 2/dev/null if [ $? -eq 0 ]; then echo [!] 公开可列清单: $bucket $OUTPUT_DIR/vulnerable_buckets.txt # 可以进一步尝试下载、上传需授权 fi done echo [] 扫描完成。潜在脆弱桶列表: $OUTPUT_DIR/vulnerable_buckets.txt这个脚本只是一个骨架。在实际操作中你需要加入错误处理、速率限制避免被AWS屏蔽、更复杂的桶名模式生成以及与其他工具如nuclei的S3检测模板的联动。4. S3存储桶漏洞深度利用与权限提升发现一个配置不当的桶只是开始如何证明其危害并挖掘更深层次的价值才是体现渗透测试工程师功力的地方。4.1 漏洞类型与利用手法详解公开可读List Read这是最常见的问题。你可以像浏览文件夹一样查看所有文件。利用方式敏感信息挖掘仔细检查所有文件。常见敏感文件包括.env环境变量含数据库密码、API密钥、config.*、backup.sql、*.pem/*.key私钥、passwords.txt等。源代码泄露桶里可能是整个网站的源代码或移动应用的APK/IPA文件通过反编译可以分析更多漏洞。数据关联分析文件名和目录结构本身可能就是情报。例如/clients/、/invoices/、/employee_records/这样的目录名直接指明了数据性质。公开可写Write这是极其危险的情况。攻击者可以直接上传文件。利用方式投递恶意软件上传包含恶意脚本的文件并诱骗内部用户访问如果桶是内部使用的。覆盖关键文件如果桶用于存储网站静态资源如JS、CSS覆盖这些文件可实现持久化攻击或供应链投毒。上传Web Shell如果该桶同时配置了静态网站托管s3-website你可以上传一个HTML/JS文件作为Web Shell通过预签名URL或直接访问来执行命令通常需要与其他服务联动。为其他攻击铺路上传一个包含恶意代码的配置文件当服务器或应用程序从该桶拉取配置时触发。桶策略与IAM角色滥用这是更隐蔽的漏洞。桶策略可能允许来自特定AWS服务如Lambda、EC2或特定VPC的访问。如果攻击者能够在其控制的资源上例如通过SSRF漏洞在目标EC2上执行代码获取临时的IAM角色凭证就可能通过该角色访问本应内部使用的S3桶。这需要你对AWS的权限模型IAM Policies, Resource-based Policies有深入理解。4.2 从S3到整个AWS环境的横向移动一个脆弱的S3桶往往不是孤立的它可能是通往整个AWS账户的跳板。凭证泄露在公开桶中找到的不仅仅是业务数据更可能是access_key_id和secret_access_key。一旦获得有效的IAM用户密钥你就可以使用AWS CLI或SDK以该用户的身份执行操作。第一步永远是使用aws sts get-caller-identity确认凭证有效性和所属身份。权限侦察拿到凭证后不要急着搞破坏。先进行安静的权限侦察aws iam list-attached-user-policies --user-name username查看用户附加的策略。aws iam list-user-policies --user-name username查看内联策略。使用Pacu、Enumerate-IAM或WeirdAAL等自动化工具系统地枚举该凭证拥有的所有权限。重点检查是否能创建新的EC2实例、Lambda函数、或提升其他用户的权限。利用过度权限如果该凭证拥有s3:PutBucketPolicy权限攻击者可以直接修改桶策略为自己或任意AWS账户授予访问权限实现权限维持。如果拥有iam:*相关权限则可能直接创建具有管理员权限的新用户。实操心得在渗透测试中当你通过公开桶获取到凭证时立即暂停。与客户确认测试范围是否允许使用这些凭证进行更深度的横向移动。未经明确授权使用泄露的凭证访问其他服务是严重的越界行为。5. 防御视角如何避免成为别人的靶子作为渗透测试者我们不仅要会攻击更要理解如何防御。给开发者和运维人员的建议往往比一份漏洞列表更有价值。5.1 S3安全配置最佳实践默认拒绝按需开放创建S3桶时务必禁用所有公共访问权限。在AWS控制台的“权限”-“阻止公共访问”设置中勾选所有四个选项。这是最重要的安全基线。使用IAM策略而非桶策略或ACL尽可能使用IAM策略来精细控制访问。桶策略和ACL更容易配置错误。IAM策略可以精确到“哪个IAM角色/用户”在“什么条件下”可以“对哪些资源”执行“哪些操作”。启用并强制使用加密静态加密启用默认的SSE-S3加密或使用客户管理的KMS密钥SSE-KMS以获得更细粒度的控制。传输中加密强制要求使用HTTPSTLS可以在桶策略中通过aws:SecureTransport条件键来实现拒绝所有非HTTPS的请求。启用全面的日志记录和监控启用S3服务器访问日志记录所有对桶的请求虽然有一定延迟但对事后分析至关重要。与CloudTrail集成确保CloudTrail日志记录S3的API调用默认已开启并将日志文件存储到另一个安全的、不可公开访问的S3桶中。使用MacieAWS Macie可以自动发现和分类S3桶中的敏感数据如个人身份信息PII并发出警报。5.2 在CI/CD流程中嵌入安全检测将安全左移在资源创建阶段就发现问题。基础设施即代码IaC扫描在Terraform、CloudFormation或AWS CDK代码提交时使用Checkov、Terrascan、cfn-nag等工具进行扫描。这些工具内置了针对S3公开访问、未加密等不安全配置的检测规则。策略即代码使用AWS Organizations的SCP服务控制策略或第三方工具在账户级别强制执行安全策略例如禁止创建公开的S3桶、强制对所有S3桶启用加密。定期自动化审计使用AWS Config规则如s3-bucket-public-read-prohibited、s3-bucket-public-write-prohibited或开源工具如Prowler、ScoutSuite定期对整个AWS账户进行安全评估主动发现配置漂移和违规项。6. 渗透测试实战案例复盘与避坑指南理论说再多不如一个实战案例来得直观。这里我分享一个经过脱敏处理的真实评估案例其中融合了多个关键点。目标对一家电商平台进行授权的外部渗透测试。过程OSINT阶段通过子域名枚举发现assets.customer.com的CNAME记录指向cdn.customer.com.s3.amazonaws.com。这是一个强烈的S3桶信号。验证与枚举使用AWS CLI匿名访问aws s3 ls s3://cdn.customer.com/ --no-sign-request成功返回文件列表确认桶公开可读。进一步浏览发现大量产品图片、CSS和JS文件。深度挖掘在列举文件时发现一个名为/config/的目录。尝试访问s3://cdn.customer.com/config/staging.env成功下载。该文件包含数据库连接字符串、第三方API密钥以及一个AWS IAM用户的访问密钥备注为“用于备份的只读用户”。权限提升使用获取的AWS密钥配置CLI执行aws sts get-caller-identity确认凭证有效。使用自动化枚举脚本发现该用户不仅拥有对多个S3桶的只读权限还附加了一个内联策略允许对特定Lambda函数进行lambda:UpdateFunctionCode操作。横向移动通过更新该Lambda函数的代码植入了简单的反向Shell。由于该Lambda函数由CloudWatch Events定时触发且其执行角色拥有VPC内EC2实例的SSMSystems Manager权限最终实现了在核心业务服务器上执行命令获取了更高权限的立足点。踩坑与心得坑1速率限制在匿名枚举桶内文件时过于频繁的请求触发了AWS的HTTP 503 Slow Down错误。解决方案在脚本中加入随机延迟sleep或者使用--request-payer参数如果桶启用了请求者付费但这会留下日志。坑2日志意识在测试写入权限时即使客户授权直接上传一个test.html也可能被对方的日志监控发现。解决方案上传的文件名尽量与桶内现有文件风格一致或者使用预签名URL进行测试减少在桶日志中留下过于突兀的记录。心得1上下文是关键找到的AWS密钥一定要在客户授权的测试环境中验证和使用。我曾遇到过在测试环境发现的密钥在生产环境无效避免了无意义的操作。心得2影响评估重于漏洞证明证明一个S3桶可公开读取很容易但更重要的是评估里面数据的敏感性。一张公开的产品图和一个包含用户手机号的数据库备份风险等级天差地别。在报告中必须对数据分类和潜在业务影响进行详细说明。7. 常见问题排查与工具排错实录在实际操作中你会遇到各种错误信息。快速理解并解决它们能节省大量时间。现象/错误信息可能原因排查步骤与解决方案aws s3 ls返回AccessDenied1. 桶不存在。2. 桶存在但禁止公开列表。3. 你的网络有出口限制某些公司网络。1. 使用s3scanner或cloud_enum确认桶名正确性。2. 尝试直接访问一个已知或猜测的文件路径如https://bucket.s3.region.amazonaws.com/robots.txt。3. 更换网络环境如使用手机热点测试。aws s3 cp下载文件返回403 Forbidden文件或桶的读取权限未公开或需要特定请求头/参数。1. 检查对象ACL或桶策略是否对匿名用户开放s3:GetObject。2. 某些资源如CloudFront后的S3可能需要特定的Referer头。可尝试用浏览器或curl -H “Referer: ...”测试。3. 对象可能使用了KMS加密匿名用户无解密权限。The bucket you are attempting to access must be addressed using the specified endpoint你使用的S3服务端点区域与桶所在的区域不匹配。1. 使用aws s3api get-bucket-location --bucket BUCKET_NAME需认证获取桶的区域。2. 或者在匿名情况下尝试常见的区域端点如s3.us-east-1.amazonaws.com,s3.eu-west-1.amazonaws.com等。3. 使用工具如s3scanner会自动处理区域发现。工具扫描大量返回NoSuchBucket生成的候选桶名列表质量不高或目标确实没有那么多桶。1. 优化关键词。使用公司名、产品名、环境dev, staging, prod的组合而非随机字典。2. 关注目标网站源代码、JS文件中的硬编码路径提取潜在桶名模式。3. 降低扫描速率避免因请求过快被临时屏蔽。获取到AK/SK后aws sts get-caller-identity返回InvalidClientTokenId访问密钥IDAK不存在或已失效。1. 确认密钥复制无误没有多余空格或换行。2. 密钥可能已被轮换、禁用或删除。这在渗透测试中很常见找到的往往是过期凭证。3. 确认使用的AWS CLI配置文件~/.aws/credentials中区域设置正确。最后我想强调的是云渗透测试尤其是针对AWS和S3是一个对细节和流程要求极高的领域。它要求你不仅是一个会使用工具的黑客更要成为一个理解云架构、身份与访问管理、以及安全最佳实践的研究者。保持好奇心严谨地记录每一个步骤并始终在授权的边界内行动这份严谨和专业性才是你在每一次测试中能够交付真正价值的关键。每一次成功的“利用”背后都应该是为了帮助客户构建更坚固的防线而不是为了炫技。