Cette méthode se base sur une faille du protocole DNS. Plutot brutale, c'est une attaque très efficace et très puissante car il n'existe aucune génération de daemons DNS qui lui échappe pas même WindowsNT/2000, cet article vous présente les méthodes utilisées lors de ce genre d'attaques.
Kom Website : http://www.chez.com/keep/KoM/dns.htm
1.0 Introduction
Un nom de domaine identifie un noeud. A chaque noeud est attribu‚ un ensemble d'informations sur des
ressources, lequel peut être vide. L'ensemble d'informations de ressources associ‚ à un nom particulier
est compos‚ de quatre enregistrements de ressources séparés (RR). L'ordre des RR dans un ensemble
n'est pas significatif, et ne doit pas n‚cessairement etre préservé par les serveurs de noms, les
résolveurs, ou tout autre partie du DNS.
Lorsque nous parlons d'un RR spécifique, nous supposons qu'il contient les éléments suivants :
owner nom de domaine o— le RR est trouvé
Type une valeur encodée sur 16 bits spécifiant le type de ressource décrit par cet enregistrement. Les
types se r‚fèrent à une définition abstraite des ressources.
Ce m‚mo d‚finit les types suivants :
A
adresse d'hôte
CNAME
nom canonique d'un alias
HINFO
CPU et le système d'exploitation (OS) d'un hôte
MX
sch‚ma d'‚change de courrier pour ce domaine. Voir [RFC-974] pour plus de d‚tails
NS
serveur de noms "autoris‚" pour le domaine
PTR
pointeur vers une autre partie de l'espace de noms de domaines
SOA
d‚but d'une sphère d'autorit‚
class valeur encodée sur 16 bits identifiant une famille de protocoles ou une instance d'un protocole.
Ce mémo définit les classes suivantes :
IN
système Internet
CH
système Chaotique
TTL
durée de vie du RR. Cette valeur est repr‚sent‚e sous forme d'un entier sur 32 bits et est exprimée en
secondes, et est principalement utilis‚e par les résolveurs lorsqu'ils m‚morisent temporairement des RR.
Le champ TTL définit combien de temps un RR peut être gardé localement avant de devoir être considéré
comme obsolète.
RDATA
type et parfois les données dépendantes de la classe d‚crivant la ressource :
A Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi d'une
adresse octale Chaotique sur 16 bits.
CNAME
nom de domaine
MX
valeur de préférence sur 16 bits (la plus basse possible) suivie d'un nom d'hôte souhaitant servir
d'‚changeur de courrier pour le domaine de l'owner.
NS
nom d'hôte
PTR
nom de domaine
SOA
plusieurs champs
Le nom du propriétaire (owner) est souvent implicite, plutôt que formant une partie int‚grante du RR. Par
exemple, de nombreux serveurs de noms repr‚sentent l'espace de nom en interne sous forme d'arbre ou
de tableaux associatifs, et pointent les RR à partir des nouds. Le restant des donn‚es des RR, soit l'en-
tête fixe (type, classe, TTL) valable pour tous les RR, et la partie variable (RDATA) adapt‚e au type de
ressource d‚crite, ‚tant habituellement stock‚e à l'ext‚rieur de la repr‚sentation de la structure de
l'espace.
La signification du champ TTL est la dur‚e limite pendant laquelle un RR peut être conserv‚ dans un
cache local. Cette limite ne s'applique pas aux donn‚es "autorisées" stock‚es dans les zones ; celles-ci
disposent aussi d'une temporisation, mais définie par la politique de rafraŒchissement de la zone elle-
même. La TTL est d‚finie par l'administrateur pour toute la zone contenant cet enregistrement. Alors
qu'une valeur faible de la TTL peut être utilis‚e pour diminuer la dur‚e de cache, et qu'une valeur de z‚ro
empêche tout stockage local, l'analyse r‚elle des performances d'Internet suggère que cette valeur soit de
l'ordre de quelques jours pour un hôte type. Lorsque l'on peut anticiper sur une modification, la TTL pourra
être r‚duite juste avant d'effectuer la modification pour optimiser la consistance de l'information au
moment du changement, puis être r‚tablie à sa valeur d'origine après un certain d‚lai.
Les données dans la section RDATA d'un RR est stockée comme une combinaison de chaŒnes binaires et
de noms de domaines. Les noms de domaines seront souvent utilisés à titre de "pointeurs" sur d'autres
structures de données du DNS.
1.0.1 Transfert de Zone
Une partie du travail d'un administrateur de zone est de maintenir l'‚tat des zones dans chacun des
serveurs de noms autorisés pour celles-ci. Lorsque des modifications, in‚vitables, sont report‚es, elles
doivent l'être sur tous les serveurs de noms associés à la zone. Bien que la distribution des donn‚es
puisse se faire par FTP ou toute autre proc‚dure de transfert cons‚quente, la m‚thode préférée sera le
transfert de donn‚es de zone par le protocole DNS lui-même.
Lorsque la v‚rification conclue en une diff‚rence de numéros de série, le serveur secondaire devra
demander un transfert de données de zone via une requête AXFR pour cette zone. La requête AXFR peut
retourner une erreur, telle que "refusé", mais donne suite en temps normal à la réception d'une séquence
de messages de r‚ponse. Les premier et dernier messages doivent contenir les données du noud
autorisé de plus haut niveau dans la zone. Les messages intermédiaires transportent tous les autres RR
enregistrés pour la zone, les RR non autorisés y compris. Le flux de messages permettent au serveur
secondaire de reconstituer une copie conforme de la zone. Comme la pr‚cision est essentielle, on
utilisera TCP ou tout autre protocole fiabilis‚ pour les requêtes AXFR.
1.1 Exemples
Exemple de requête classique :
[nobody@victime /]$ host -l victime.com
victime.com name server ns1.victime.com
victime.com name server ns2.victime.com
victime.com has address 127.0.0.1
linux.victime.com has address 192.168.1.2
mail.victime.com has address 192.168.1.3
ns1.victime.com has address 192.168.1.5
ns2.victime.com has address 192.168.1.7
pigeon.victime.com has address 192.168.1.1
Ceci va g‚n‚rer un message dans les logs du server
Apr 29 20:07:54 victime.com named[1407]: approved AXFR from [127.0.0.1].9611 for
"victime.com"
Ceci nous permet d'obtenir la configuration. Notez que le fichier DNS est plus complexe lors
d'une requête AXFR
[nobody@victime /]$ host -l -v -t any victime.com
rcode = 0 (Success), ancount=1
Found 1 addresses for ns1.victime.com
Trying 127.0.0.1
victime.com 86400 IN SOA ns1.victime.com
root.localhost(
1997022700 ;serial (version)
28800 ;refresh period
14400 ;retry refresh this often
3600000 ;expiration period
86400 ;minimum TTL
)
victime.com 86400 IN NS ns1.victime.com
victime.com 86400 IN NS ns2.victime.com
victime.com 86400 IN A 127.0.0.1
victime.com 86400 IN MX 1 mail.victime.com
linux.victime.com 86400 IN A 192.168.1.2
mail.victime.com 86400 IN A 192.168.1.3
ns1.victime.com 86400 IN A 192.168.1.5
ns1.victime.com 86400 IN HINFO Celeron 400
ns2.victime.com 86400 IN A 192.168.1.7
machine1.victime.com 86400 IN A 192.168.1.1
machine2.victime.com 86400 IN HINFO CISCO IOS
victime.com 86400 IN SOA ns1.victime.com root.localhost(
1997022700 ;serial (version)
28800 ;refresh period
14400 ;retry refresh this often
3600000 ;expiration period
86400 ;minimum TTL
)
Nous poss‚dons d‚sormais le fichier configuration avec quelques infos : MAIL (MX) DNS (NS) ;
Informations (HINFO)
Ces dernières infos auraient pu être obtenues de façon diff‚rente
host -t mx victime.com (pour avoir les mails serveurs)
host -t A victime.com (pour avoir les entr‚es standards)
host -t ns victime.com (pour avoir les dns serveurs)
etc...
1.2 Explication
Au moment o— le server de nom primaire (ns1) est d‚marr‚, il copie les informations sur les
entr‚s (A; NS; MX ...) vers le secondaire (ns2) via ce que l'on appel un transfert de zone.
Donc les informations de zone (A, NS, MX, HINFO ...) sont aussi consultables depuis le NS2.
2.0 Secure DNS Bypassing
2.1 M‚thode par serveur secondaire
Supposons maintenant que l'AXFR soit refus‚ sur victime.com
[nobody@victime /]$ host -l victime.com
Server failed: Query refused
[nobody@victime /]$
Ce type de message signifie que le DNS est prot‚g‚ et refuse les requêtes AXFR.
Mais certaines requêtes sont toujours autoris‚s puisque NS et MX sont toujours lisible.
Ces requêtes vitales au fonctionnement du r‚seau permettent respectivement de convertir les
noms d'hôtes en adresse IP et de permettre la r‚ception de mail.
Exemple :
[nobody@victime /]$ host -t ns victime.com
victime.com name server ns1.victime.com
victime.com name server ns2.victime.com
[nobody@victime /]$
Les 2 serveurs DNS sont ns1.victime.com et ns2.victime.com
Voici comment obtenir leurs IP respectifs
[nobody@victime /]$ host ns1.victime.com
ns1.victime.com has address 192.168.1.5
[nobody@victime /]$
[nobody@victime /]$ host ns2.victime.com
ns1.victime.com has address 192.168.1.7
[nobody@victime /]$
La phase suivante est la cl‚ du bypassing
echo " " > /etc/resolv.conf
echo " " >> /etc/resolv.conf
echo "nameserver 192.168.1.5" >> /etc/resolv.conf
echo " " >> /etc/resolv.conf
[nobody@victime /]$ host -l victime.com
Server failed: Query refused
[nobody@victime /]$
Si ça ne marche pas, on essaye avec le DNS suivant
echo " " > /etc/resolv.conf
echo " " >> /etc/resolv.conf
echo "nameserver 192.168.1.7" >> /etc/resolv.conf
echo " " >> /etc/resolv.conf
[nobody@victime /]$ host -l victime.com
victime.com name server ns1.victime.com
victime.com name server ns2.victime.com
victime.com has address 127.0.0.1
linux.victime.com has address 192.168.1.2
mail.victime.com has address 192.168.1.3
ns1.victime.com has address 192.168.1.5
ns2.victime.com has address 192.168.1.7
pigeon.victime.com has address 192.168.1.1
Nous avons simplement contact‚ le serveur DNS secondaire non prot‚g‚ contre la lecture pour
lire les informations prises sur le premier serveur.
2.2 M‚thode par reverse
Un DNS correctement configur‚ gère les reverses. Cela signifie qu'une adresse IP pointe vers
un nom.
192.168.1.7 pointe vers ns2.vicitme.com (en r‚alit‚ il ne regarde pas le reverse de 192.168.1.7 mais
plutôt le PTR : 7.1.168.192.in-addr.arpa IN PTR ns2.victime.com. )
Reprenons depuis la requête refus‚e dans le première m‚thode
[nobody@victime/]$ host -l victime.com
Server failed: Query refused
[nobody@victime /]$
[nobody@victime /]$ host -t ns victime.com
victime.com name server ns1.victime.com
victime.com name server ns2.victime.com
[nobody@victime /]$
[nobody@victime named]$ host -t mx victime.com
victime.com mail is handled (pri=1) by mail.victime.com
[nobody@victime named]$
Nous ne pouvons toujours pas r‚aliser d'AXFR mais nous pouvons d‚jà obtenir les IP de ces 3
serveurs
[nobody@victime named]$ host ns1.victime.com
ns1.victime.com has address 192.168.1.5
[nobody@victime named]$
[nobody@victime named]$ host ns2.victime.com
ns1.victime.com has address 192.168.1.7
[nobody@victime named]$
[nobody@victime named]$ host mail.victime.com
mail.victime.com has address 192.168.1.3
[nobody@victime named]$
Apparemment, tout le r‚seau victime.com se trouve sur la classe d'adresse 192.168.1.X.
Vous pouvez par ailleurs utiliser la commande whois sur le RIPE ou sur l'ARIN pour connaŒtre
les classes d'adresse exactes du r‚seau cible.
Dans l'exemple, la solution consiste à obtenir les reverse des adresses IP.
Pour, vous ‚viter de faire: host 192.168.1.1 ; host 192.168.1.2 ; host 192.168.1.3 etc.
Voici le g‚notype d'un programme r‚alis‚ par la Team Cryptel
/* ----------------------------------- CUT HERE --------------------------------*/
main(int argc, char *argv[]){
int i;
if(argc != 2){
printf("Usage : %s 192.168.1.
", argv[0]);
exit(0);
}
for(i = 1; i > exec-ce-check
host -t ns victime.com >> exec-ce-log
host -t mx victime.com >> exec-ce-log
sh ./exec-ce-check >> exec-ce-log
Vous avez ainsi reçu une partie de la configuration.
3.0 ID DNS Hacking
Vous devez s–rement vous demander ce que le hacking ou spoofing d'ID DNS peut bien être. Le hacking
d'ID DNS est n'est pas une m‚thode de hacking très courante (en tout cas moins que le blind spoofing ou
le bind spoofing). Cette m‚thode se base sur une faille du protocole DNS. Plutot brutale, c'est une attaque
très efficace et très puissante car il n'existe aucune g‚n‚ration de daemons DNS qui lui ‚chappe pas
même WindowsNT/2000 !
La seule manière pour un daemon DNS de diff‚rencier les diff‚rentes question/r‚ponses est le marqueur
ID dans le paquet.
Exemple :
ns.server.com:53 --->[?www.victime.com] ---> ns.victime.com:53
Vous avez juste besoin de spoofer l'IP de ns.victime.com et r‚pondre vos fausses informations à
ns.server.com avant ns.victime.com !
ns.server.com > Oct 06 05:18:12 ADM named[1913]: db_free: DB_F_ACTIVE set - ABORT
A ce moment, le NS est hors service.
- Vous pouvez utiliser les faiblesses BIND d‚couvertes, avec les pr‚visions d'ID.
3.1 Faiblesse ID Windows
L'ID est des plus faciles à deviner car il est ‚gal à 1 par d‚faut et 2 pour la seconde query, s'il y en a 2 à la
fois.
3.2 Faille BIND
Pour connaŒtre un ID, il vous suffit de sniffer le DNS. Le DNS utilise un ID al‚atoire au d‚but, puis
l'incr‚mente ensuite pour les query suivantes...
a. Il est facile de sniffer le message allant vers un DNS al‚atoire (ex: ns.server2.com)
b. Vous demandez à ns.victime.com de r‚soudre (hasard).server2.com. Ns.victime.com va demander à
ns.server2.com de retrouver *.server2.com
ns.victime.com ---> [?*.server2.com ID = 666] ---> ns.server2.com
c. Maintenant que vous connaissez l'ID du message, vous savez quelle ID utiliser maintenant (666 dans
cet exemple pr‚cis).
d. Maintenant, vous faite votre demande de r‚solution.
Exemple : www.victime.com vers ns.victime.com
(vous) ---> [?www.microsoft.com] ---> ns.victime.com
ns.victime.com ---> [?www.microsoft.com ID = 446 ] ---> ns.microsoft.com
e. Inondez le serveur ns.victime.com avec l'ID que vous avez obtenu (666), et alors, vous vous
l'incr‚mentez.
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 666] --> ns.victime.com
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 667] --> ns.victime.com
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 668] --> ns.victime.com
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 669] --> ns.victime.com
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 670] --> ns.victime.com
ns.microsoft.com --> [www.microsoft.com = 1.1.1.1 ID = 671] --> ns.victime.com
Vous savez maintenant que les ID Dns sont pr‚visibles, et qu'ils ne font qu'augmenter. Vous inondez
ns.victime.com avec des r‚ponses bidons à l'ID 666+.
3.3 Technique alternative
Une autre technique existe sans n‚cessiter d'être root sur un DNS. Le m‚canisme est fort simple, on
envoie à ns.victime.com une demande de r‚solution pour *.isp.fr
(vous) ----------[?*.isp.fr] -------> ns.victime.com
Puis, ns.victime.com demande à ns1.isp.fr de retrouver (hasard).isp.fr.
Rien de nouveau jusqu'ici except‚ qu'à partir de là, vous commencez à inonder ns.victime.com avec de
fausses r‚ponses (avec l'IP de ns1.isp.fr), avec des ID allant de 100 à 110.
(spoof) ----[*.isp.fr is 1.2.3.4 ID=100] --> ns.victime.com
(spoof) ----[*.isp.fr is 1.2.3.4 ID=101] --> ns.victime.com
(spoof) ----[*.isp.fr is 1.2.3.4 ID=102] --> ns.victime.com
(spoof) ----[*.isp.fr is 1.2.3.4 ID=103] --> ns.victime.com
etc...
Après cela, on demande à ns.victime.com si (hasard).isp.fr a une IP.
Si ns.victime.com nous donne une IP pour *.isp.fr, c'est bon.
Sinon il ne vous reste plus qu'à recommencer. Le mieux ‚tant de faire ça à plusieurs pour plus de rapidit‚,
d'efficacit‚ et de discr‚tion.
Pour toutes pr‚cisions concernant le DNS, consultez les RFC-1034 et 1035.
|
