子域名接管
| , 3 minutes reading.
1. 定义
子域名接管 发生在子域名的 DNS 记录指向已被取消配置或从未正确配置的外部服务(如云托管、CDN 或 SaaS 平台)时。攻击者可以声明这个未配置的资源,从而有效控制该子域名。
这个漏洞很危险,因为:
- 攻击者控制着您受信任域名下的内容
- 作用于父域名的 Cookie 可能被访问
- 用户信任该子域名是合法的
- 可被用于钓鱼、凭据窃取或恶意软件分发
2. 技术原理
如何发生:
- 公司创建
blog.example.com指向云服务(如 GitHub Pages、Heroku、AWS S3)。 - 后来,云资源被删除,但 DNS 记录仍然存在。
- 子域名现在指向一个未被认领的资源。
- 攻击者在云平台上创建同名的新资源。
- 攻击者现在控制了
blog.example.com。
易受攻击的 DNS 记录类型:
- CNAME 记录:
blog.example.com CNAME example.github.io- GitHub 仓库已删除 - A 记录: 指向可被重新分配的已释放云 IP
- NS 记录: 委托给攻击者可以注册的名称服务器
常见易受攻击的服务:
| 服务 | 指示器 | 接管方法 |
|---|---|---|
| GitHub Pages | 404 - “There isn’t a GitHub Pages site here” | 创建匹配名称的仓库 |
| Heroku | ”No such app” | 创建同名应用 |
| AWS S3 | ”NoSuchBucket” | 创建同名存储桶 |
| Azure | ”404 Web Site not found” | 声明资源名称 |
| Shopify | ”Sorry, this shop is currently unavailable” | 注册 myshopify.com 子域名 |
| Fastly | ”Fastly error: unknown domain” | 将域名添加到 Fastly 账户 |
3. 攻击流程
sequenceDiagram
participant DNS as DNS 服务器
participant Attacker as 攻击者
participant User as 受害用户
participant Cloud as 云服务提供商
Note over DNS: blog.example.com<br/>CNAME → old-app.herokuapp.com<br/>(资源已删除)
Attacker->>Cloud: 检查 old-app 是否可用
Cloud-->>Attacker: 资源名称可用
Attacker->>Cloud: 创建名为 old-app 的新应用
Cloud-->>Attacker: 应用创建成功
Attacker->>Cloud: 部署恶意内容
User->>DNS: 解析 blog.example.com
DNS-->>User: CNAME → old-app.herokuapp.com
User->>Cloud: 请求 old-app.herokuapp.com
Cloud-->>User: 攻击者控制的内容<br/>在 example.com 子域名下提供
Note over User: 用户看到合法的<br/>example.com 域名<br/>信任该内容4. 真实案例:Vine (Twitter) 子域名接管 (2014)
目标: Vine(Twitter 的视频平台)。 漏洞类别: 通过 Fastly CDN 的子域名接管。
漏洞背景: 安全研究公司 Detectify 发现 attachments.vine.co 有一条指向 Fastly CDN 的 CNAME 记录,但 Fastly 配置已被移除。
攻击场景:
- 子域名
attachments.vine.co指向 Fastly。 - Fastly 返回错误,表明该域名未配置。
- 任何拥有 Fastly 账户的人都可以声明这个域名。
- 攻击者随后可以在
attachments.vine.co上提供任意内容。
潜在影响:
- Cookie 窃取: Vine 的会话 Cookie 可能作用于
*.vine.co,这意味着攻击者可以窃取用户会话。 - 钓鱼: 用户看到 URL 中的
vine.co会信任该内容。 - OAuth 劫持: 如果 Vine 使用这个子域名进行 OAuth 回调,攻击者可以拦截令牌。
解决方案: Twitter 通过其漏洞赏金计划收到通知,并及时移除了悬空的 DNS 记录。
5. 深度防御策略
A. DNS 卫生
维护所有 DNS 记录的准确清单。
- 定期审计: 定期审查所有 DNS 记录,验证它们指向活跃资源。
- 退役流程: 在取消配置云资源之前,始终先移除 DNS 记录。
- 文档: 记录每个子域名由哪个团队负责。
# 审计脚本示例
for subdomain in $(cat subdomains.txt); do
result=$(dig +short $subdomain)
if [ -z "$result" ]; then
echo "DANGLING: $subdomain"
fi
doneB. 自动化监控
使用工具持续扫描易受攻击的子域名。
- 工具:
subjack- 子域名接管检测nuclei- 带有接管模板的漏洞扫描器can-i-take-over-xyz- 社区维护的易受攻击服务列表
# 使用 subjack
subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -sslC. 主动声明资源
即使您不使用某项服务,也要声明命名空间。
- 策略: 使用您的域名在主要云平台上创建占位资源。
- 示例: 如果您拥有
example.com,在 GitHub、Heroku 等上声明example。
D. 使用经过验证的域名所有权
选择验证域名所有权的云服务。
- 验证方法:
- TXT 记录验证
- HTTP 文件验证
- Meta 标签验证
具有适当验证的服务可以防止攻击者声明您的域名。
E. Cookie 安全
如果子域名被攻陷,限制爆炸半径。
- 显式域名范围: 设置带有显式域名的 Cookie(无前导点)。
- 分离 Cookie 域名: 对敏感 Cookie 使用不同的域名。
__Host-前缀: 对只应由主机设置的 Cookie 使用__Host-前缀。
# 坏:所有子域名可访问
Set-Cookie: session=abc123; Domain=.example.com
# 好:仅 www.example.com 可访问
Set-Cookie: session=abc123; Domain=www.example.com
# 最好:主机绑定 Cookie
Set-Cookie: __Host-session=abc123; Secure; Path=/F. 实施 CAA 记录
限制哪些证书颁发机构可以为您的域名颁发证书。
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"这可以防止攻击者为被接管的子域名获取 SSL 证书。
G. 所有子域名的安全标头
即使是非生产子域名也应该有安全标头。
Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff