CoreDNS CVE-2026-35579 : bypass d'authentification TSIG sur gRPC, QUIC, DoH et DoH3

CoreDNS — le serveur DNS écrit en Go, devenu le DNS par défaut de Kubernetes — vient d'être affecté par une vulnérabilité d'authentification majeure. CVE-2026-35579 (CVSS 9.8) révèle que les transports modernes (gRPC, QUIC, DoH, DoH3) ne valident jamais correctement le HMAC TSIG sur les requêtes entrantes. Concrètement, n'importe quel attaquant peut contourner les protections TSIG qui sécurisent les transferts de zone (AXFR/IXFR), les mises à jour DDNS et tous les plugins TSIG-gated.

Sur DoH et DoH3 c'est encore pire : l'attaquant n'a même pas besoin de connaître un nom de clé TSIG valide.

Détails techniques

Mécanisme TSIG et raison d'être

TSIG (Transaction SIGnature, RFC 8945) est le mécanisme d'authentification des messages DNS via HMAC. Il sécurise classiquement :

• Les transferts de zone (AXFR, IXFR) entre serveur primaire et secondaires
• Les DNS Updates dynamiques (RFC 2136)
• Les plugins CoreDNS configurés pour exiger TSIG

L'authentification se déroule en 2 étapes :

1. Le serveur vérifie que le nom de clé TSIG envoyé correspond à une clé configurée
2. Le serveur vérifie que le MAC (HMAC) calculé sur le message correspond à celui attendu

Le bug

Sur gRPC et QUIC

Le serveur vérifie bien que le nom de clé existe dans la configuration… mais n'appelle jamais dns.TsigVerify() pour valider le HMAC. Le champ interne tsigStatus reste nil, et le plugin tsig traite la requête comme authentifiée avec succès quelle que soit la valeur du MAC.

Sur DoH et DoH3

Plus grave encore : la méthode DoHWriter.TsigStatus() renvoie systématiquement nil sans inspecter quoi que ce soit. Le serveur ne regarde même pas l'enregistrement TSIG. Toute requête contenant un enregistrement TSIG est traitée comme authentifiée, même si le nom de clé est invalide et le MAC arbitraire.

// Pseudo-code reconstitué — pattern vulnérable DoH
func (w *DoHWriter) TsigStatus() error {
    return nil  // 🚨 No check at all
}

Caractéristiques

Produits et versions affectés

Vérifiez votre version :

# CoreDNS standalone
coredns -version

# Kubernetes
kubectl exec -n kube-system <coredns-pod> -- /coredns -version

# Helm
helm list -A | grep coredns

Si vous opérez CoreDNS comme service DNS interne (Kubernetes, service discovery, DDNS), vérifiez impérativement quels transports sont activés dans votre Corefile.

Exploitation et impact

Conditions d'exploitation

L'exploitation requiert que CoreDNS écoute sur au moins un des transports vulnérables (gRPC, QUIC, DoH, DoH3) et qu'au moins une protection s'appuie sur TSIG.

Configurations à risque :

# Exemple Corefile vulnérable
. {
    bind 0.0.0.0
    grpc 0.0.0.0:443        # ⚠️ transport vulnérable
    https 0.0.0.0:443       # ⚠️ DoH
    tsig {                  # ⚠️ s'appuie sur TSIG
        key zonemaster.key
    }
    file /etc/coredns/zones/db.example.com
    transfer to *
}

Conséquences

1. Transferts de zone non autorisés (AXFR/IXFR)

Un attaquant peut récupérer le contenu intégral de toutes vos zones DNS : noms internes, IPs, infrastructure cachée, mail servers, services SRV. C'est la première étape classique d'une attaque ciblée (reconnaissance).

2. DNS Updates dynamiques malicieuses (DDNS)

L'attaquant peut ajouter ou modifier des enregistrements DNS :

• Créer des sous-domaines pointant vers ses propres serveurs (phishing, C2)
• Modifier les enregistrements MX pour intercepter le mail
• Empoisonner les records pour des attaques type Kaminsky

3. Bypass des plugins TSIG-gated

Si vous utilisez des plugins CoreDNS qui n'autorisent certaines opérations qu'avec TSIG (politique d'autorisation, plugins custom), ces protections sont complètement contournées.

Pourquoi DoH/DoH3 sont particulièrement dangereux

Sur gRPC/QUIC, l'attaquant doit au moins connaître un nom de clé TSIG valide (souvent facile à deviner — key1., zonemaster.). Sur DoH/DoH3, aucune connaissance préalable n'est nécessaire. L'exploitation peut être lancée par n'importe quel attaquant capable de joindre votre serveur DoH.

Détection et IOC

Logs CoreDNS

Activez le logging des requêtes :

. {
    log
    # ...
}

Indicateurs typiques :

• Requêtes AXFR ou IXFR réussies depuis des IPs non autorisées
• Requêtes contenant un enregistrement TSIG avec un nom de clé inconnu (sur DoH/DoH3, à corréler avec des résultats positifs)
• Volume anormal de UPDATE réussis depuis des sources externes

Filtrage de logs

# Détection grossière de tentatives AXFR via DoH
grep -E "TYPE_AXFR|TYPE_IXFR" /var/log/coredns/access.log | \
  grep -v "10.0.0.0/8\|172.16.0.0/12\|192.168.0.0/16"

Audit de zones

Comparez les zones servies par CoreDNS à une sauvegarde fiable :

# Si CoreDNS sert des fichiers de zone
diff /etc/coredns/zones/db.example.com /backup/zones/db.example.com

Toute modification non corrélée à une opération admin légitime = compromission probable.

Mitigation et patch

Action immédiate : passer en 1.14.3

# Docker
docker pull coredns/coredns:1.14.3
docker compose up -d

# Kubernetes (modifier l'image dans le ConfigMap / Deployment)
kubectl set image deployment/coredns -n kube-system \
  coredns=coredns/coredns:1.14.3

# Helm
helm upgrade coredns coredns/coredns --version <chart-version> \
  --set image.tag=1.14.3

Workaround officiel (si patch impossible)

Désactivez les transports vulnérables lorsque TSIG est en jeu :

# Garder uniquement UDP/TCP classique
. {
    bind 0.0.0.0
    # GRPC, QUIC, DoH, DoH3 supprimés
    tsig {
        key zonemaster.key
    }
    # ...
}

Ou restreignez l'accès réseau aux transports affectés à des sources de confiance :

# iptables — limiter DoH (TCP 443) aux IPs admin
iptables -A INPUT -p tcp --dport 443 -s <admin-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Hardening durable post-patch

• Auditer les transferts de zone des 30 derniers jours pour détecter d'éventuelles exfiltrations
• Faire tourner toutes les clés TSIG (génération de nouveaux secrets HMAC, redéploiement sur tous les clients DDNS et secondaires)
• Restreindre par défaut les requêtes AXFR/IXFR au niveau du firewall, pas seulement via TSIG
• Surveiller activement les requêtes UPDATE réussies vers vos serveurs CoreDNS

Pourquoi surveiller en continu vos serveurs DNS

Les serveurs DNS sont des points d'infrastructure critiques : leur compromission donne à l'attaquant le contrôle de la résolution réseau de toute votre organisation. Pourtant, les inventaires de vulnérabilités traditionnels passent souvent à côté de CoreDNS — déployé comme microservice dans Kubernetes, il échappe aux scanners d'OS classiques.

Avec cveo.tech, inventoriez vos services DNS au même titre que vos serveurs Linux et soyez alerté automatiquement dès qu'une CVE critique cible CoreDNS, BIND, Unbound, Knot, PowerDNS — pour que vos résolveurs ne deviennent jamais le maillon faible de votre infrastructure.