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..."


Tout le monde s'est habitué à voir des "étoiles" quand il saisi son mot de passe sur un système, une application ou un site web.

Et ben, Jakob Nielsen appel tout bonnement à ne plus masquer les mots de passe et à les afficher en clair !

Attention, apparemment, ce n'est pas n'importe qui : co-fondateur du Nielsen Norman Group, ancien Ingénieur Sun Microsystems et auteur de plusieurs livres.

Il base son argumentaire sur le fait que l'apport en sécurité du masquage des mots de passe est négligeable par rapport aux problèmes qu'il induit.

Selon lui, d'une part, c'est rare qu'une personne se penche au dessus de vos épaules pour voir ce que vous tapez, mais d'autre part, masquer le mot de passe cause des erreurs répetées des utilisateurs, ce qui les fait, soit déserter le site en question (manque à gangner) ou choississent des mots de passe trop simple (dégradatoin du niveau de sécurité).

Vous voyez, ça ne manque pas de logique !

Et pour donner plus de crédibilité à cette idée, le célèbre cryptologue Bruce Schneier apporte son grain de sel on disant tout simplement "I agree with this".

Mais au-delà de cette idée et la polimique qu'elle peut génerer, cette histoire me rappel un billet que j'ai lu il y a quelques jours dans mon flux RSS. C'est une autre figure de la sécurité, Rich Mogull, qui fait une digression sur la nécessité en sécurité (et dans la vie en général) d'avoir une attitude "sceptique" envers notre environnement, et surout envers nos présumées "certitudes".

C'est en somme, être à la fois parano et d'un esprit scientifique !!

Difficile mode de vie à mener :)


.

J'apprends quelque part sur la toile qu'on a débattue de "l'expérience du e-commerce en Algérie" !!! Et je trouve un article sur Mobile Algérie qui reprend cette nouvelle.

Ha bon, on a de l'expérience dans l'e-commerce et on est même entrain de l'évaluer ?!!! Moi qui parlait de la nécessité de se préparer avant ... je suis dépassé par les évènements alors.

Ok, j'apprends alors par l'article qu'il "a été présentée, avant-hier à Alger, par le Touring club Algérie (TCA) et les promoteurs d'un site web de vente électronique, au deuxième et dernier jour d'une rencontre sur les expériences des pays du Maghreb dans le développement de la culture numérique".

Et que "Le directeur régional centre du TCA, Djamel Ramdani, a évoqué l'expérience menée par le Touring Club Algérie en matière de promotion du tourisme et de la destination Algérie à travers le site web de son organisme." ... où il soutient que "des réservations sont effectuées via le net au même titre que le paiement qui s'effectue à travers l'utilisation de l'Internet".

Intéressant tout ça. Je vais alors naturellement voir du côté du site de TCA pour comprendre comment ça se passe.

Déjà, c'est un domaine ".com" hébergé chez Amen en France ... mais bon, vu l'état du domaine ".dz", on peut comprendre.

Un site bien fait à première vue, mais ce qui m'intéresse c'est comment "faire de l'e-commerce" à partir de site.

L'onglet le plus parlant est "réservation"... réservons alors :)

On arrive à l'URL : http://touring-algerie.com/index.php/fre/shop/userregister

C'est du clair, pas de https malgré qu'on nous demande plein d'informations personnelles (nom, prénom,tél, émail...) !!! .... Après, on est devant un développeur qui manifestement ne sait pas (ou s'en fou) ce que veut dire contrôle des entrées :

Je met des chiffres pour les nom / prénom, des lettres pour le n° tél et le code postal....tout passe sans souci !!!

et la page me dit alors : "
Votre commande à été envoyée avec succès" ... (un "à").

Et après ? rien !!! et je cherche toujours le "e" du commerce.

J'ai peut-être raté quelque chose, alors si quelqu'un a compris quelque chose qu'il nous éclair .... rêvons en attendant de l'e-commerce algérien.

Mais on ne terminera pas sans dire que ce site est celui qui a remporté le Trophée MED-IT 2009 comme le meilleur site web marchand Algérien !!!

Je ne peut rien dire sur ça, bien que un peu surpris, mais côté sécurité c'est un peu léger ... même nos apprentis hackers peuvent faire quelque chose :)


.

Dans l'essai précédent de l'outil Honeysnap, j'ai eu à modifier manuellement le texte des traces pour garder l'anonymat du trafic réseau appartenant au client servant de cas d'étude.


Mais pour de larges quantités de traces, il faudrait faire ceci d'une manière plus propre, d'où l'intérêt des outils d'anonymisation de traces réseau.

Un des outils qui offre une grande flexibilité est PktAnon. Il a été developpé par Christoph P. Mayer, Thomas Gamer et Dr. Marcus Schöller de l'institut des télématiques de l'université de Karlsruhe en Allemagne.

Les options ou choix des modifications à apporter aux paquets originaux sont contenus dans un fichier profile sous formats XML, avec un riche panel de primitives à appliquer.

En plus des @IP source et destination, des ports source et destination (TCP ou UDP), on peut altérer plein de champ d'un paquet, allant des @MAC source et destination jusqu'au TTL.

Dans le manuel de l'outil, il y a le détail de toutes les options possibles.

Avant d'aborder l'installation et l'utilisation de cet outil, je noterais que j'ai récupérer la version 1.2.2-dev, qui était la plus récente à cet instant (la dernière semaine). La compilation n'a pas aboutie en raison de plusieurs erreurs.

J'ai envoyé alors un mail aux developpeurs de l'outil en citant les erreurs et mon environnement (version de gcc entre autre)... et 1h 25 mn après, ils me confirment que c'est lié à la dernière version de gcc que j'utilise et qu'ils vont publier une nouvelle version pour régler ce problème.

Le landemain, à 08:19 je reçois un mail m'informant de la disponibilité d'une nouvelle version, la 1.2.3-dev, compatible avec le package gcc 4.3.x ... alors bravo pour leur réactivité.

Installation :


- Récupération et décompression de l'outil :

$ wget http://www.tm.uka.de/software/pktanon/download/pktanon-1.2.3-dev.tar.gz
$ tar vxfz pktanon-1.2.3-dev.tar.gz

- Installation des paquets pré-requis : (dans le guide ils parlent de libxerces27-dev, or il n'existe pas dans les dépots Ubuntu, c'est libxerces-c2-dev à sa place)
$ sudo apt-get install libxerces-c2-dev libboost-dev

- Configuration, compilation et installation proprement dite :
$ ./configure
$ make
$ sudo make install

Utilisation :

J'ai donc une trace "capture.pcap" que je veux transmettre à un collègue ou poster sur un forum pour avoir l'avis et bénéficier de l'expertise des autres.
Je doit donc la rendre anonyme et transmettre en fait la trace "capture_anonyme.pcap" à sa place

Je décide de modifier l'@IP appartenant à mon réseau. Je veux en plus modifier l'@MAC source.

Pour faire tout ça, on prend le fichier profile fourni settings_identity.xml et on le modifie en conséquence :

- Dans le sous-module "Flow" on met :

<configitem name="Input">capture_test.pcap</configitem>
<configitem name="Output">capture_anon.pcap</configitem>


- Dans le sous-module "Checksumming", comme on va modifier certaines valeurs, la somme de contrôle va changer évidement, on met donc :

<configitem name="ReCalculateChecksums">1</configitem>
<configitem name="SetBadChecksumsToBad">1</configitem&gt
; (si un checksum initial est incorrect, on calcul un nouveau ... incorrectement)

- Dans le sous-module "EthernetPacket" on met :

<configitem anon="AnonBytewiseHashSha1" name="MacSource"/> (par défaut c'était "AnonIdentity" = garder la valeur initiale. Maintenant on change chaque octet par son Hash SHA1)

- Dans le sous-module "IpPacket" on met :

<configitem anon="AnonBytewiseHashSha1" name="IpSourceip"/&gt; (Hash SHA1 de chaque octet)


Tout est en place à présent. Il ne reste qu'à lancer la machine pktanon en précisant le fichier profile :

$ pktanon settings_identity.xml

Pour vérifier le résultat, on observe les modifications apportées au premier paquet par exemple.

L'original :

$ sudo tcpdump -neXv -c 1 -r capture_test.pcap
reading from file capture_test.pcap, link-type EN10MB (Ethernet)
18:38:47.484853 00:03:0d:3e:70:bb > 00:50:fc:25:01:2f, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11139, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.125.48706 > 74.125.99.32.80: F, cksum 0xd73f (correct), 1271021476:1271021476(0) ack 261401586 win 108
0x0000: 4500 0034 2b83 4000 4006 a07e c0a8 007d E..4+.@.@..~...}
0x0010: 4a7d 6320 be42 0050 4bc2 3fa4 0f94 abf2 J}c..B.PK.?.....
0x0020: 8011 006c d73f 0000 0101 080a 0002 37f5 ...l.?........7.
0x0030: a9b4 4922 ..I"


L'anonyme :)

$ sudo tcpdump -neXv -c 1 -r capture_anon.pcap
reading from file capture_anon.pcap, link-type EN10MB (Ethernet)
18:38:47.484853 da:c0:c5:5a:6e:f9 > 00:50:fc:25:01:2f, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 11139, offset 0, flags [DF], proto TCP (6), length 52) 246.142.218.214.48706 > 74.125.99.32.80: F, cksum 0xc6ff (correct), 1271021476:1271021476(0) ack 261401586 win 108
0x0000: 4500 0034 2b83 4000 4006 903e f68e dad6 E..4+.@.@..>....
0x0010: 4a7d 6320 be42 0050 4bc2 3fa4 0f94 abf2 J}c..B.PK.?.....
0x0020: 8011 006c c6ff 0000 0101 080a 0002 37f5 ...l..........7.
0x0030: a9b4 4922 ..I"


Alors, ceux qui ont besoin d'aide, mais hésitent à envoyer leur traces ... anonymisez :)


.

Dans le billet précédent, j'ai terminé par remarquer que des requêtes DNS me semblaient bizarres parce qu'elles répétaient la même question au serveur en changeant la casse des lettres constituant le nom de domaine.

Dans ce genre de cas, c'est un des deux :
1- On est devant un truc vraiment intéressant et original
2- C'est quelque chose de banal et de trivial, et c'est nous qui avons raté une info basique

Inutile de dire que dans le plupart des cas, c'est plutôt le 2 :)

Revenons quand même à notre intrique. A ma connaissance, et selon même les RFC 1034 et 1035, la casse n'a pas d'importance dans un nom de domaine donné (voir section Preferred name syntax).
Par exemple : machin.truc = MaChin.TRUC

Alors, pourquoi certains clients (10 exactement) émettent des requêtes en variant la casse de certaines lettres ?!!

J'avoue que j'ai cherché à déceler la combinaison selon laquelle se font les variations, à voir de plus près qui sont ces clients bizarres pour moi ... en construisant plein d'hypothèses, des plus anodines au plus invraisemblables.

Mais après cette dose de paranoïa, une voix de lucidité est venue me souffler qu'il fallait peut-être voir du côté de l'ami Google s'il n'y avait pas quelque chose du même genre.

Après quelques minutes, je trouve l'explication qui me convient (pour le moment :) )

Toute cette histoire est liée aux techniques de lutte contre le cache poisoning des resolveurs DNS.

Les méchants essayent d'induire en erreur les clients DNS en leur fournissant de fausses-vraies réponses en se substituant au serveur DNS demandé.

Pour lutter contre ce type d'attaque, l'idée est d'avoir le plus possible de valeurs non (ou difficilement) déduisables par l'attaquant.

Deux éléments d'une transaction DNS sont largement connu et implémentés, surtout suite aux travaux de Dan Kaminsky de l'année passée. Ce sont le port UDP source et l'IDentifiant de la transaction. Il s'agit de les rendre le plus aléatoires possibles....mais ça reste jouable pour un attaquant s'il a le temps et les ressources suffisantes.

L'idée alors est de compliquer encore plus la vie de l'attaquant, en ajoutant un autre élément aléatoire ... vous avez deviné, c'est la casse des lettres constituant la question à résoudre. Le concept a été proposé par Paul Vixie et David Dagon sous forme d'un INTERNET-DRAFT de l'IETF en Mars 2008 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity".

En gros, ils proposent que le resolveur envoi une requête en variant la casse de la question. Les serveurs DNS en leur majorité, bien que les RFC ne le disent pas, copient bit à bit la question pour l'utiliser dans leur réponse.

Exemple, je demande à un serveur DNS de résoudre le nom www.SitE.Dz . Dans ses enregistrements, le serveur a l'@IP correspondante à www.site.dz, mais il va me répondre "www.SitE.dZ = 10.10.1.1" en respectant la casse comme il l'a reçu.... et là, le client en vérifiant la réponse, va savoir si c'est le vrai serveur qu'il a interrogé et c'est un autre qui veut l'induire en erreur.
Pour faire passer son coup, l'attaquant doit prédire la bonne combinaison en minuscule et en majuscule...en plus du bon port UDP...en plus du bon TXID .

Cette idée est petit à petit implémentée dans plusieurs resolveurs DNS (celui utilisé par tor par exemple) .

Enfin, ça explique (pour le moment) mes requêtes suspectées à tord .... désolé d'avoir douté de vous cher resolveurs 0x20 :)


.

J'ai essayé ces derniers jours d'exploiter les résultats obtenus par l'outil Honeysnap dans le but d'analyser « sommairement » des captures réseau sur un ensemble de serveurs.

J'ai pris comme traces celles d'une entreprise cliente qui a, en DMZ externe, un serveur Web, un serveur DNS et un serveur Webmail (le serveur de messagerie est dans une autre zone).

Mais, c'est facilement faisable sur une petite architecture perso …. pour voir qui s'intéresse à nous :)

Et croyez moi ... on découvre des choses intéressantes :)

Concrètement, j'ai créé deux scripts : Analyse_DNS et Analyse_WEB

Analyse_DNS :

1- En premier, je lance Honeyscan sur la capture dns.pcap, en spécifiant les options suivantes :

"-H$1" : on donne ici (comme argument au script) l'@IP du serveur DNS.

"--do-dns" : pour demander l'extraction des données DNS (requêtes et réponses)

"--do-incoming" : sommaire des flux entrants vers le serveur

"--do-outgoing" : sommaire des flux sortants du serveur


Ce qui donne :

honeysnap -H$1 --do-dns --do-incoming --do-outgoing $2 (l'argument 2 est le fichier capture)

Les résultats sont par défaut dans le sous-répertoire « output » du répertoire courant, avec l'@IP comme sous-sous-répertoire.


2- On va voir les différents flux entrants (TCP et UDP), par ordre croissant des occurrences et uniquement le top 20 par exemple :

cat output/$1/conns/incoming.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")" | awk '{print $14 }' | sort | uniq -c | sort -g | tail -n 20 > $1_flux_in_top20.txt

Dans mon cas, ça donne ceci :

1 23
1 38933
1 38940
…................
1 39452
1 39465
2 22
441656 53

Les connexions telnet et ssh sont légitimes d'après ce que j'ai vu avec les admins.

Les paquets vers les ports 3**** sont des réponses DNS

Et naturellement (à première vue), le gros, c'est des requêtes DNS …. vers un serveur DNS


3- Alors, je voudrais maintenant voir le top 10 des adresses sources :

cat output/$1/conns/incoming.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")" | awk '{print $11 }' | sort | uniq -c | sort -g |tail -n 10 > $1_src_top10.txt

Çà donne quelque chose du genre (désolé … c'est des traces privées du client )

57 80.*.*.*
78 80.*.*.*
90 207.*.*.*
114 219.*.*.*
138 123.*.*.*
462 192.168.0.10 0
3207 192.168.1.169
4788 192.168.1.104
55695 192.168.0.190
72288 192.168.0.189

Les @IP internes constituent le plus gros volume de communications....normale apparemment


4- On a vu le trafic entrant, et le trafic sortant ?

Voyons le top 10 des destinations …. réseau, pas celles de voyagealgerie.com :)

cat output/$1/conns/outgoing.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")"| awk '{print $13 }' | sort | uniq -c | sort -g |tail -n 10 > $1_dst_top10.txt

ça donne (désolé encore :) )

60 80.*.*.*
90 207.*.*.*
114 219.*.*.*
138 123.*.*.*
150 80.*.*.*
546 192.168.0.10 0
3207 192.168.1.169
4794 192.168.1.104
55695 192.168.0.190
72288 192.168.0.189

Globalement, c'est cohérent avec les flux entrant …. pas de quoi nécessiter une analyse approfondie.


5- Étant dans le cas d'un serveur DNS, il serait normale de s'intéresser au données DNS proprement dites.

Commençant par le top 20 des requêtes DNS :

cat output/$1/dns/dns_served.txt | egrep "("Fri"|"Sat"|"Sun"|"Mon"|"Tue"|"Wed"|"Thu")"| awk '{print $10 }' | sort | uniq -c | sort -g |tail -n 20 > $1_req_top20.txt

et le résultat est (re-désolé ;) )

3 *.*/*.*.*.*.IN-ADDR.ARPA
3 ns.moi.Dz
5 ns.moi.DZ
20 *.*/*.*.*.*.IN-ADDR.ARPA
22 webmail.moi.dz
47 *.*/*.*.*.*.in-addr.arpa
69 *.*/*.*.*.*.in-addr.arpa
72 ,
109 *.*/*.*.*.*.IN-ADDR.ARPA
176 www.moi.dz
219 *.*/*.*.*.*.IN-ADDR.ARPA
470 *.*/*.*.*.*.in-addr.arpa
516 *.*/*.*.*.*.in-addr.arpa
907 *.*/*.*.*.*.in-addr.arpa
1393 moi.dz
1903 1*.*/*.*.*.*.in-addr.arpa
4078 www.test.moi.dz
85583 ns.moi.dz

Alors déjà les 72 requêtes sur « , » c'est un peu bizarre.

Mais après investigation sur le fichier trace et en comparant aux fichiers produits par honeysnap , je remarque que toutes les requêtes « ratées » sont de type « any ».

Un bug ? Mes traces qui sont coupables ? Pas le temps de faire d'autres tests avec d'autres traces.

Un truc attire mon attention : 3 requêtes pour « ns.client.Dz » et 5 pour « ns.client.DZ »

Vous avez remarqué le « z » contre le « Z » ?!!

Çà mériterait peut-être un peu plus d'analyse .... je traiterais cela dans un prochain billet :)


.


Un petit billet annonce / promo / pub :)

C'est pour signaler un nouveau portail " qui visera tous ce qui tourne autours du voyages, des métiers liés à ce dernier, du tourisme et surtout de la destination Algérie" .... c'est www.voyageralgerie.com

Il a l'ambition de devenir un espace fédérateur des activités liées au tourisme et au voyage .... souhaitons bonne continuation et pleine réussite à cette initiative :)

En plus du portail Web, on a droit aussi à un blog : http://voyages-algerie.blogspot.com

Enfin, l'initiateur du projet est Karim Khelouiati ... alias ktalgerie :)


.

Inscription à : Articles (Atom)