e-Construction : Mon cyber-journal perso

"L'intelligence c'est d'apprendre de ses erreurs, la sagesse c'est d'apprendre de celles des autres..."


en flag Read it in english



La faille découverte par Dan Kaminsky a fait, fait encore et fera sûrement l'actualité pour quelque temps. Plusieurs chercheurs se penchent sur l'état des serveurs DNS en terme de déploiement des patchs. Le constat n'est globalement pas très rassurant.

Alors qu'en est-il des serveurs DNS des domaines « dz » ?
Certains diront déjà, avec assurance et sans aucune vérification, que le parc de ces DNS est « pourri » :-) .... en se basant sur l'état de sécurité général des sites algériens.

Difficile de les contredire :-)

Dans ce billet, j'ai essayé de recueillir des « faits » qui peuvent « relativement » donner un état de nos serveurs DNS. Je dis « relativement », parce que dans cette première partie, je m'intéresse à certains serveurs uniquement (essentiellement universitaires). Cependant, tout les tests ont été validés manuellement (pas de script exécutant automatiquement les tests) ce qui donne un certain crédit aux résultats....au moins pour moi :-)

Concrètement, j'ai fait une recherche sur les sites web des universités ou centres universitaires Algériens. Parmi les sites existant, 29 utilisent leurs propres serveurs DNS, les autres utilisent ceux du Cerist.
En plus, j'ai testé les serveurs appartenant à quelques fournisseurs de services.

Pour chaque serveur DNS trouvé, j'ai récupéré la version du service directement quand c'est possible en la corellant avec le résultat d'un outil de finger-printing DNS (fpdns) :

dig @ServDNS txt chaos version.bind
fpdns ServDNS

Un autre test consistait à vérifier si le serveur acceptait la récursivité. Enfin, le dernier test concerne la célèbre faille Kaminsky en utilisant le service du site « dns-oarc.net » :

dig +short @ServDNS porttest.dns-oarc.net TXT

Les résultats, que vous trouverez ici, sont classés selon l'ordre croissant des versions du service DNS.

Alors quelques remarques :

1- La médaille d'or revient à l'université de Annaba (ns.univ-annaba.dz). C'est LE SEUL serveur récursif DNS patché (porttest donne Great) au moment où j'ai effectué les tests. En plus, c'est le deuxième plus récent (version 9.3.4-P1.1) de la liste, après ns.eepad.dz. Mais pourquoi en fait récursif ? Ils sont généreux les benois :-)

2- 73,17 % (30/41) des serveurs sont récursif...et 96,66 % (29/30) de ceux récursifs sont vulnérables à la dernière faille de Kaminsky.

3- Tout les serveurs sont sous BIND, sauf UN, celui de l'université de Guelma (serveur.univ-guelma.dz), il est en « Microsoft Windows DNS 2000 » ....ce n'est pas très sérieux !

4- Quatre (04) serveurs ont modifié le fichier de configuration BIND pour « cacher » la version

- Les plus « intelligents » sont les deux serveurs de nedjma avec « ATTEMPT LOGGED! » (tentative enregistrée) :-)
Mais bon, il faudrait peut-être commencer par mettre à jour les serveurs, actuellement entre 8.3.0-RC1 et 8.4.4 d'après l'outil fpdns. Ont-ils modifié le comportement de BIND pour induire en erreur l'outil ?!! Un bon point tout de même, ils ne sont pas récursifs.
- Le serveur de l'APS (hogar.aps.dz) répond par « unknown », mais fpdns dit qu'il est dans l'intervalle 9.2.0rc7–9.2.2-P3. En plus, il semble qu'il forwarde les requêtes à ns1.tda.dz !
- Le serveur de TDA (ns2.tda.dz) n'a pas du tout le sens de la communication :-), sa réponse est « ». fpdns croit qu'il est dans 9.2.3rc1--9.4.0a0

Dans un prochain billet, je vais essayer d'avoir un échantillon plus important en incluant les résultats de recherche sur Google de tous les sites « dz ». L'analyse sera totalement automatisée...mais ça risque d'avoir quelques erreurs.

en flag Read it in english




Un lisant un billet sur la difficulté de marier entre sécurité et facilité d'utilisation ou convenance, je me suis souvenu d'un constat que j'ai fait en vérifiant la validité des couplets user/password de la messagerie Wissal du Cerist qu'un "super hacker" a posté sur forumdz.com.
Ce qui a attiré mon attention, c'est la gestion des erreurs lors des accés. Les administrateurs ont soit priviligié la "convenance" sur la sécurité...et ils sont libres, c'est leur choix, ou (et là c'est plus problématique) ils ne sont pas conscients de la "vulnérabilité" qu'ils ont laissé.

Alors de quoi s'agit-il ?

Simplement , le site en question nous renseigne sur l'existance ou non d'un compte indépendament de la validité du mot de passe.

Vous me diriez que ce n'est pas vraiment grave....peut-être, mais pour moi ça divise en deux l'effort à fourir en brute-force; On ne test que le password. Et quand on sait que les mêmes compte sont généralement utilisés pour d'autres choses, on voit bien l'importance de la chose.

Vérifiant ensemble :


j'aime bien le "toto" des français :)


Ok, là une très bonne gestion du message d'erreur, pas d'indiquation sur la cause du rejet...mais...mais

ils vous disent "Veuillez vérifier".... vérifier quoi ?!


Ha bon, vous n'avez pas de compte "toto" .....

Hummm, essayons un autre compte et vérifiant du coups :

On nous donne même les dates de création et d'expiration !!! Merci c'est très gentil :)


Essayons le fameux root :

interessant...




Maintenant, est-ce qu'on va les essayer un à un ? évidement non :)
L'url qui fait la vérificatioon est donnée en cadeaux et en clair :)

http://wissal.dz/register/checkAccountLdap.php?compte=CompteToTest

Il ne reste qu'à faire un petit script pour automatiser le tout, du genre :

For CompteToTest in Dictionnaire
url de validation
Recuperer comptes valides

Alors avant de finir, trois petites remarques :

1- Ces vulnérabilités, qu'on peut appeler "conceptuelles" ou de design ne sont pas le propres de nos sites, c'est presque la règle
2- Je suis toujours fidèle à ce que j'ai dit dans mon premier billet de ce blog (pas de hack). Ce que je viens de montrer ne compromet pas directement le serveur, en plus je vais signaler mon billet aux admin du site en question
3- Je n'ai aucune animosité envers le Cerist, d'ailleur j'en ne connais personne. Mais être gestionnaire du domaine DZ, implique des responsabilités et un niveau de sécurité "acceptable".

en flag Read it in english



Il y a bien longtemps que je n'est pas posté......quoi ? on doit justifier nos revenues, travailler quoi :)
Certes, il y avait de l'actualité qui méritait un petit billet, mais bon....

Alors vous me direz qu'est ce qui vous a si dérangé pour réagir ? Je dirais simplement : la médiocrité !

On apprend, avec une certaine "fierté" qu'on a dorénavant notre google : google.dz.
A chaque accès à un service google, on est (nos autres résidents en Algérie) rediriger vers ce nouveau site/domaine.
Or, ce qu'on a, ce n'est pas l'accès mais une page d'erreur !!! (il parait que ça a marché un jour). Le grand Internet ne connait pas notre cher domaine google.dz....honte à lui.
Alors, essayons de voir qui est le vrai coupable. Mettons nous à la place d'un internaute Algérien, avec sa configuration DNS la plus générale (serveur de djawab, OpenDNS ou autres) :

1- Interrogeons la "RACINE" de l'architecture DNS mondiale, à défaut de savoir tout sur tout, elle nous montre le chemin :

dig @E.ROOT-SERVERS.NET www.google.dz (choix au hasard d'un des serveurs root, le E)

Résultats :










Le serveur racine ne connaissant pas la réponse, nous renvoie vers les serveurs autoritaires de la zone "dz", au nombre de 4 (le ns3.nic.fr est "autoritaire" sur "dz"..svp ne voyez aucune signification extra-technique, c'est de la redondance :))

2- Interrogeons maintenant ces serveurs autoritaires, à défaut de donner la réponse directe (@ IP), forcement ils nous indiqueront où aller :
















Il sont unanimes, le serveur autoritaire sur google.dz est gdns.google.dz
Ce gdns (g comme google je présume) doit connaitre le www.google.dz
Une précision : son @ IP est 193.194.64.84, qui appartient au Cerist.

3- Interrogeons le concerné alors (tout resolveur DNS fera cette démarche en fait) :

dig @193.194.64.84 www.google.dz (j'utilise l'@ IP parce que le nom gdns.google.dz me pose problème, mais bon on revient à la case départ)
..................
…………….. ANSWER: 0

Et quelques fois :
...............
;; connection timed out; no servers could be reached

4- Conclusion : il n y a pas de www.google.dz pour le moment (...et alors !!! les gens du Cerist ont droit aux vacances comme tout le monde, non !!), et ça sera résolu le moment venu comme nous a rapporter ButterflyOfFire après avoir contacter le Cerist.

En fait, si un gars comme ButterflyOfFire était au Cerist je ne croix pas que ce billet aura existé :).....en plus il a les traits d'un sherlock holmes :)

UPDATE : 13/08/2008

et bien le Cerist a réagi en mettant ce qu'il fallait, un petit CNAME :

www.google.dz. 300 IN CNAME www.google.com.


UPDATE : 16/12/2008

Un saut dans le temps :) .... c'est encore les vacances au Cerist !!

Inscription à : Articles (Atom)