子域名漏洞如何排查

从攻击面分析到防御加固实战

目录导读

1. 子域名漏洞的核心威胁 – 了解为何子域名成为攻击者突破口
2. 常见子域名漏洞类型 – DNS劫持、CNAME接管、敏感信息泄露等
3. 排查工具与扫描策略 – 从被动收集到主动验证的完整流程
4. 漏洞修复与防御加固 – 配置审计、记录清理、监控预警
5. QA问答 – 解决排查中的高频难题

子域名漏洞的核心威胁

子域名是域名系统中的“末梢神经”，但常被企业忽视，攻击者利用子域名漏洞实施钓鱼攻击、权限提升或数据窃取，主要原因有三：

• 管理疏漏：开发测试环境、过期子域名未被及时清理。
• 配置错误：DNS记录指向已失效的第三方服务（如云存储、CDN）。
• 缺乏监控：子域名数量庞大（尤其大型企业），人工难以全覆盖。

真实案例：某电商平台测试子域名test.shop.example未设置A记录，攻击者注册同名Amazon S3 Bucket并托管恶意页面，最终窃取用户支付信息。

常见子域名漏洞类型

1 DNS劫持与区域传送漏洞

• 原理：DNS服务器配置错误导致允许未授权区域传送（AXFR请求），攻击者可获取全部子域名记录。
• 检测方法：使用dig axfr @目标DNS服务器 目标域名测试。

2 CNAME/NS记录接管漏洞

• 原理：子域名的CNAME或NS记录指向已释放的第三方托管服务（如GitHub Pages、Heroku、AWS S3），攻击者可注册同名资源实现内容控制。
• 典型案例：cdn.example.com指向example.azureedge.net，但Azure Edge服务已过期，攻击者可创建同名端点注入恶意脚本。

3 敏感信息泄露

• 场景：子域名暴露后台管理页面（admin.example.com）、遗留的.git目录、未加密的API端点。
• 风险：攻击者可通过目录扫描或搜索引擎（如Google dork）发现这些端点。

4 证书透明度（CT）暴露

• 原理：SSL/TLS证书日志公开包含所有子域名，即使未在DNS中直接列出，攻击者可利用CRT.sh等平台收集隐藏子域名。

排查工具与扫描策略

1 被动收集阶段（不直接触碰目标）

• 证书透明度查询：使用crt.sh或curl -s "https://crt.sh/?q=%.example.com&output=json"获取证书域名。
• 搜索引擎挖掘：site:example.com -www配合inurl:admin查找公开页面。
• DNSSec/DNS记录分析：通过dnsrecon -d example.com -t axfr测试区域传送。

2 主动验证阶段（需授权）

• DNS枚举工具：
  • subfinder -d example.com -o subdomains.txt（基于被动源）
  • amass enum -d example.com -o output.txt（结合被动+主动扫描）
• 服务存活检测：httpx -l subdomains.txt -o alive.txt验证HTTP/HTTPS可达性。
• 漏洞专扫工具：
  • 接管漏洞：subjack -w alive.txt -t 100 -ssl（匹配已知服务指纹）。
  • CNAME检查：python3 takover.py -l subdomains.txt（基于规则库）。
  • 敏感路径扫描：gobuster dir -u http://[子域名] -w common.txt。

3 自动化流水线（示例）

被动收集：subfinder + crt.sh
2. 主动解析：dnsx -l passive.txt -o resolved.txt
3. 服务检测：httpx -l resolved.txt -o alive.txt
4. 漏洞扫描：subjack + nuclei -t subdomain-takeover.yaml
5. 结果聚合：notify或输出至告警系统

漏洞修复与防御加固

1 清理过时记录

• 操作：在DNS管理平台中删除已过期子域名（如dev.example.com）、废弃CNAME指向。
• 验证：使用dig [子域名] ANY确认无残留记录。

2 配置安全锁定

• 区域传送限制：在DNS服务器配置中仅允许授权IP发起AXFR请求。
  • BIND示例：allow-transfer { 192.168.1.0/24; };
• 开启DNSSEC：防止解析过程被篡改。

3 监控与预警

• 实时检测：部署subdomain_monitor脚本或使用Cloudflare等DNS托管服务的自动扫描功能。
• 变更告警：对DNS记录变更设置日志审计（如AWS Route53的ChangeLog）。

4 漏洞修复案例

场景：发现api.example.com的CNAME指向example.awsapps.com（过期WorkMail服务）。 修复步骤：

1. 在DNS控制台删除此CNAME记录。
2. 若该子域名需继续使用,更新为正确的A记录（指向自有服务器）。
3. 在AWS中确认example.awsapps.com无残留S3存储桶或CloudFront分发。

QA问答：排查高频难题解析

Q1：如何区分“被接管”与“正常CDN/云服务”？

A：查看返回的HTTP头部或SSL证书信息。

• 被接管：返回404 Not Found且页面含有This bucket is not configured等字样（如S3）。
• 正常服务：包含X-Cache: Hit from cloudfront或Server: nginx/1.20.1。
• 建议工具：curl -v [子域名] 2>&1 | grep -i "Server\|X-Amz"。

Q2：子域名太多，如何确定优先级？

A：按风险等级排序：

• 高危：CNAME指向第三方（云服务、托管平台）且可公开访问。
• 中危：无CNAME但响应404（可能被解析到默认IP，易被IP劫持）。
• 低危：无解析记录但曾暴露在CT日志中（需评估历史用途）。

Q3：扫描时被WAF/IDS拦截怎么办？

A：采用无源（passive）方法为主：

• 仅使用证书日志、搜索引擎、Wayback Machine历史记录。
• 如需主动扫描,将请求频率降至1次/秒，并使用随机User-Agent和IP池（如Tor代理）。

Q4：内部子域名（如intranet.example.com）如何排查？

A：确保其不暴露在公共DNS中：

• 检查是否通过www.example.com的.htaccess或反向代理暴露。
• 使用nslookup从外部网络验证：若返回NXDOMAIN，则安全；否则需立即修改DNS记录。

子域名漏洞排查不是一次性任务,而是持续的安全实践，建议企业建立“发现-验证-修复-监控”的闭环机制，并定期（如每月）执行自动化扫描，对于大型组织，可将子域名清单集成到漏洞管理平台（如DefectDojo），实现全生命周期跟踪。

行动清单：

1. 本周：使用crt.sh和subfinder收集所有子域名。
2. 本月：针对CNAME接管和敏感目录进行专项扫描。
3. 季度：审计DNS区域传送配置和DNSSEC状态。

提示：未授权扫描可能违反目标网站的服务条款，请确保在拥有合法授权的前提下进行测试。