HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > DANE et les attaques par rejeu
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|DANE et les attaques par rejeu  

by Florian Maury (16/05/2012)



==================================================================
DANE et le problème des attaques par rejeu de DNSSEC
==================================================================

  DANE est une technologie développée par les ingénieurs de l'IETF. Elle
modifie la confiance portée en des certificats reçus dans le cadre d'une
connexion à un serveur SSL/TLS. Pour cela, DANE définit un nouvel
enregistrement DNS de type TLSA.
Il permet de :

    o restreindre l'origine des certificats utilisés à :
        o certaines autorités de certification ;
        o certains certificats, issus d'autorités de certification dans le 
          magasin du client SSL/TLS.

    o ajouter une ancre de confiance pour la requête en cours et à laquelle 
raccrocher le certificat reçu par le client SSL/TLS ;

    o lister des certificats, auto-signés ou issus d'une autorité de 
certification ne figurant pas dans le magasin, devant être acceptés.

  Ces restrictions ou additions étendent le modèle classique reposant sur les
magasins de certificat des clients SSL/TLS. Pour cette raison, l'intégrité de
la réponse doit pouvoir être garantie. En effet, si un attaquant pouvait en 
altérer le contenu, il pourrait insérer une ancre de confiance pour un
certificat qu'il contrôle et ainsi opérer une attaque Man-In-The-Middle sur
toutes les connexions chiffrées de sa victime.  Pour assurer l'intégrité des
données, les auteurs de DANE ont imposé l'utilisation de DNSSEC.

  DNSSEC repose sur le principe de la signature cryptographique des 
enregistrements. La signature porte sur les données de l'enregistrement 
protégé auxquelles sont ajoutées notamment deux dates : la date de création de
la signature et la date d'expiration à partir de laquelle la signature est 
considérée comme invalide.

  La signature des enregistrements est effectuée à l'heure actuelle hors
ligne, éventuellement sur une machine autre que les serveurs faisant autorité
sur la zone signée. Cette manière de signer les données permet d'utiliser la
clé privée sur une machine moins exposée aux attaques provenant de l'Internet
et ainsi de limiter l'impact que pourrait avoir une compromission d'un serveur
faisant autorité.
  La contre-partie de cette méthode de signature est sa nature statique. Aucune
information n'est signée lors de la requête ce qui empêche la signature d'un
aléa unique (nonce) qui serait fourni lors de la requête. 
DNSSEC est donc vulnérable aux attaques par rejeu.
  Si cette vulnérabilité est connue, elle reste souvent tue et demeure un
problème ouvert.

  On peut lire régulièrement que la date d'expiration de la signature est une 
protection contre les attaques par rejeu, car son exploitation est limitée
dans le temps.
  Certes, la date d'expiration permet de limiter de manière effective la période
pendant laquelle une attaque par rejeu est possible (si tant est que le
résolveur validant les signatures conserve son horloge synchronisée ; ce qui
est un problème à part entière et mérite une seconde de réflexion), et l'on 
pourrait se dire que plus court est l'intervalle de validité de la signature,
meilleure est la sécurité.

  Hélas, ce n'est pas le cas. 
  La sécurité est certes définie par un critère d'intégrité mais également de 
disponibilité.
  Le choix de la période de validité d'une signature DNSSEC influe en effet
directement sur la disponibilité d'une zone (sa résilience ("survivability")),
et est intrinsèquement lié aux paramètres de réplication de
la zone entre le serveur maitre et le ou les serveurs esclaves. La période
avant expiration de la zone chez les esclaves non actualisés est
particulièrement importante.

  Le mécanisme de réplication standard, dans les infrastructures DNS se base
en effet sur le transfert de zone, dont la fréquence est contrôlée par le
deuxième entier de l'enregistrement SOA ("Start Of Authority") de la zone
répliquée. Si un serveur secondaire ne parvient pas à joindre son maître,
alors il entre en phase de ré-essai, dont l'intervalle est défini par le
troisième entier de l'enregistrement SOA. Si malgré les ré-essais, la zone ne
parvient pas à être réactualisée, la zone est défaussée des serveurs esclaves
après une période d'une durée égale au quatrième entier de l'enregistrement
SOA.
  Cette période d'expiration additionnée au TTL de l'enregistrement signé
définit le temps minimal de validité d'une signature. Si l'intervalle de
validité de la signature devait être plus court, alors les serveurs esclaves
pourraient servir des enregistrement dont la signature est expirée. Cela se
produirait même si le serveur maître dispose d'une nouvelle signature en cours
de validité puisque la réplication ne serait plus assurée.

  Zonecheck [1], utilitaire bien connu permettant de contrôler les propriétés
d'une zone et des serveurs auxquels elle est déléguée, conseille d'utiliser 
une période d'expiration d'au minimum 1 semaine, selon la politique de 
l'AFNIC.
  La signature devrait donc avoir une période de validité d'au moins une
semaine, pendant laquelle un attaquant peut rejouer un enregistrement sans que
cela ne puisse être détecté. Réduire l'intervalle avant expiration d'une zone
auprès d'un serveur secondaire est certes possible, mais cela réduit d'autant
la résilience globale de la zone en cas d'incapacité à rafraichir la-dite
zone, ce qui, in fine, revient également à dégrader le critère de
disponibilité.

  La durée de vie d'une signature est donc très largement supérieure à la
durée de vie de la transaction qui a généré la requête ayant déclenché sa
récupération.
Cela signifie dans le cadre de DANE que dans le cas où une clé privée serait
compromise, l'intégralité des clients DANE pourraient être la cible d'attaques
par rejeu qui permettraient à l'attaquant d'user de manière transparente un
certificat dérobé sans qu'aucune révocation ne soit possible. Ce risque est
nouveau et induit par DANE.

  Un papier, publié en 2008 [2], tente de limiter la portée des attaques
par rejeu, tout en permettant des périodes de validité des signatures longues.
Les auteurs y présentent un nouvel enregistrement DNSSEC, nommé RRSIG-H. Cet
enregistrement reprend l'ensemble des informations comprises dans un
enregistrement RRSIG standard mais y ajoute des condensats cryptographiques.
Ce condensat est issu d'une chaîne de condensats de Lamport. L'utilisation de
cette chaine de condensats permet de limiter l'intervalle de vulnérabilité aux
attaques par rejeu à une période égale à deux fois le TTL de l'enregistrement
signé.

  Le principe correspond à l'utilisation de la propriété à sens unique des
fonctions de hachage cryptographique. Pour cela, on calcule un nombre de
condensats égal à la période de validité de la clé divisée par le TTL de
l'enregistrement signé, tel que :

  Pour h une fonction hachage cryptographique :
  h(0) = h(une valeur aléatoire)
  h(n) = h(h(n-1))

 Le dernier condensat calculé est intégré dans l'enregistrement de type RRSIG-H 
et signé en même temps que les données standards d'un enregistrement RRSIG.

  Les serveurs faisant autorité sur la zone n'ont alors qu'à fournir au
client DNS l'enregistrement DNS correspondant à la question posée, sa
signature contenant le dernier condensat, signé, et le condensat "en cours".
Ce dernier correspondant au X-ième antécédant au condensat signé, tel que

  X = (date actuelle - date de création de la signature) / TTL

  Un client cherchant à valider la réponse n'a alors qu'à calculer X 
(ou X + 1) fois le condensat du condensat "en cours" et le comparer au
condensat signé pour vérifier l'intégrité de la réponse.

  Le défaut de cette approche est que le nombre de condensats antécédants à
stocker est très important, si l'on désire les cacher. Il faut en effet alors
cacher une chaine de condensats par enregistrement d'une zone. Le nombre de
condensats dans la chaine explose également proportionnellement avec le ratio
[ période de validité de la signature / TTL ]. Les TTL très courts (de
l'ordre de la seconde) sont alors quasiment impossible à gérer.
Le nombre de chaines de condensats est encore plus important dans la
proposition originale puisque les auteurs souhaitent permettre de distinguer
les serveurs esclaves en leur permettant d'utiliser une chaine de condensats
différents par esclave. 
Ce dernier point est peut-être la raison pour laquelle cette proposition a été
totalement ignorée par la communauté, puisqu'il est particulièrement
discutable. 
De fait, 4 ans après, aucune implémentation publique des enregistrements
RRSIG-H n'existe, et le problème des attaques par rejeu des enregistrements
signés avec DNSSEC reste donc ouvert.

  Comment résoudre ce problème ?
  Une solution pourrait être de déléguer les enregistrements TLSA à des serveurs
dont la signature se fait en ligne. Chaque signature aurait alors une durée de
vie égal au TTL de l'enregistrement, sans pour autant mettre en danger la
résilience de la zone parente.
Les enregistrements TLSA devraient alors être signés à l'aide d'une bi-clé
différente de celle de la zone parente afin de limiter l'impact de sa
compromission.

  Il est bien sûr possible, en fonction des risques encourus par le métier
d'utiliser DNSSEC pour sécuriser les enregistrements TLSA sans procéder à une
telle délégation. Il est cependant alors nécessaire d'être conscient des
limitations de DNSSEC, et de choisir avec sagesse une durée de signature
conciliant disponibilité et intégrité.

==================================================================
Florian Maury
==================================================================
[1] http://www.zonecheck.fr
[2] http://irl.cs.ucla.edu/~eoster/doc/npsec_08-revocation.pdf



Last modified on 16 May 2012 at 17:44:22 CET - webmaster@hsc.fr
Information on this server - © 1989-2010 Hervé Schauer Consultants