Category Archives: Various

DNSRecon, Yet Another DNS Informations Gathering Tool

DNSRecon, outil développé en ruby par Carlos Perez (aka Darkoperator), développeur pour le projet MetaSploit et membre de la team PaulDotCom, est tous comme Fierce, ou DNSEnum, un outil de récupération d’informations par le biais des DNS.

Tous comme DNSEnum, DNSRecon effectue une récupération par le biais des “reverses lookup” d’adresses IP. Mais à la différence de DNSEnum qui va découvrir de part lui même les réseaux associés à un nom de domaine, il faut spécifier à DNSRecon une adresse IP de départ et une adresse IP de fin pour la récupération des “reverses lookup”. Cette option est intéressante, car DNSEnum, dans un certain sens, ne nous laisse pas le choix des réseaux à scanner, tandis que DNSRecon nous donnera cette liberté.

ruby dnsrecon.rb -r adresse_ip_de_depart adresse_ip_de_fin serveur_de_dns_alternatif

Une fonctionnalité que par exemple DNSEnum, ou Fierce, n’ont pas est la récupération d’information automatique sur tous les TLD associé à un nom. DNSRecon va automatiquement regarder si un nom de domaine existe pour un certaine liste de TLD, et fournir directement le ou les adresses IP associées. Il est possible facilement de rajouter des TLD à DNSRecon en modifiant le code (par exemple, DNSRecon n’intègre pas le TLD .lu dans sa liste)

82 "com", "org", "net", "edu", "mil", "gov", "uk", "af", "al", "dz",
83 "as", "ad", "ao", "ai", "aq", "ag", "ar", "am", "aw", "ac","au",
84 "at", "az", "bs", "bh", "bd", "bb", "by", "be", "bz", "bj", "bm",
85 "bt", "bo", "ba", "bw", "bv", "br", "io", "bn", "bg", "bf", "bi",
86 "kh", "cm", "ca", "cv", "ky", "cf", "td", "cl", "cn", "cx", "cc",
87 "co", "km", "cd", "cg", "ck", "cr", "ci", "hr", "cu", "cy", "cz",
88 "dk", "dj", "dm", "do", "tp", "ec", "eg", "sv", "gq", "er", "ee",
89 "et", "fk", "fo", "fj", "fi", "fr", "gf", "pf", "tf", "ga", "gm",
90 "ge", "de", "gh", "gi", "gr", "gl", "gd", "gp", "gu", "gt", "gg",
91 "gn", "gw", "gy", "ht", "hm", "va", "hn", "hk", "hu", "is", "in",
92 "id", "ir", "iq", "ie", "im", "il", "it", "jm", "jp", "je", "jo",
93 "kz", "ke", "ki", "kp", "kr", "kw", "kg", "la", "lv", "lb", "ls",
94 "lr", "ly", "li", "lt", "lu", "mo", "mk", "mg", "mw", "my", "mv",
95 "ml", "mt", "mh", "mq", "mr", "mu", "yt", "mx", "fm", "md", "mc",
96 "mn", "ms", "ma", "mz", "mm", "na", "nr", "np", "nl", "an", "nc",
97 "nz", "ni", "ne", "ng", "nu", "nf", "mp", "no", "om", "pk", "pw",
98 "pa", "pg", "py", "pe", "ph", "pn", "pl", "pt", "pr", "qa", "re",
99 "ro", "ru", "rw", "kn", "lc", "vc", "ws", "sm", "st", "sa", "sn",
100 "sc", "sl", "sg", "sk", "si", "sb", "so", "za", "gz", "es", "lk",
101 "sh", "pm", "sd", "sr", "sj", "sz", "se", "ch", "sy", "tw", "tj",
102 "tz", "th", "tg", "tk", "to", "tt", "tn", "tr", "tm", "tc", "tv",
103 "ug", "ua", "ae", "gb", "us", "um", "uy", "uz", "vu", "ve", "vn",
104 "vg", "vi", "wf", "eh", "ye", "yu", "za", "zr", "zm", "zw", "int",
105 "gs", "info", "biz", "su", "name", "coop", "aero" ]

ruby dnsrecon.rb -tld zataz serveur_de_dns_alternatif

De nouveau, tous comme DNSEnum ou Fierce, DNSRecon propose une récupération d’informations “brute force” par le biais d’un fichier contenant tous les sous-domaines que vous désirez tester. Malheureusement, comme Fierce, DNSRecon ne propose pas une mise à jour du fichier contenant tous les sous-domaines qui auraient pu être découverts par les autres options de DNSRecon.

ruby dnsrecon.rb -b zataz.com dns.txt serveur_de_dns_alternatif

Une autre fonctionnalité de DNSRecon est la récupération d’informations basée sur les entrées NS, entrées SOA et entrées MX associées au nom de domaine cible.

ruby dnsrecon.rb -s zataz.com serveur_de_dns_alternatif

Une tentative de transfert de zone est aussi possible par le biais de DNSRecon, tous comme pour DNSEnum ou Fierce.

ruby dnsrecon.rb -axfr zataz.com

Les solutions Cloud ne sont pas “compliant” avec PCI

Malgré toutes les bonnes volontés, il ne se passe pas un jour sans que l’on retrouve des données bancaires sur Internet, soit par le biais d’un piratage, soit tous simplement par le biais d’un “Google Hacking“. Ces données bancaires dérobées et exploitées par des pirates informatiques mettent à mal le commerce électronique et la confiance des internautes dans les paiements en ligne.

Vous connaissez sûrement tous le standard PCI qui promeut la protection des données de paiement tels que vos données personnelles, vos identifiants et surtout votre numéro de carte bancaire, sa date d’expiration et son cryptogramme visuel. Le forum PCI Security Standards Council a élaboré desstandards de sécurité qui nécessitent des pré-requis pour la gestion quotidienne de la sécurité, autant en terme technique, qu’en terme de règles de sécurité et de processus.

De plus en plus d’entreprises, ont alors décidées de rejoindre le forum PCI et de se faire certifier compliant PCI-DSS, afin de redorer leurs images et des redonner de la confiance aux internautes envers les paiements en ligne.

Malheureusement, ces mêmes entreprises, dans le même temps, toujours en recherche d’économie d’échelle, se sont montrées très intéressées par les solutions Cloud, tels que les SaaS (Cloud Application), PaaS (Cloud Software Environment) et IaaS (Cloud Infrastructure). De nombreux chercheurs en sécurité informatique, ainsi que de nombreux professionnels de la sécurité doutaient déjà à l’époque de la possibilité d’affirmer qu’une solution Cloud soit complètement sécurisé et compliant avec de nombreux standards.

Amazon avec ses solutions Cloud EC2 et S3 (IaaS), a malheureusement confirmé, en toute honnêteté, qu’il serait impossible pour une entreprise utilisant ses solutions d’obtenir le niveau 1 du standard PCI-DSS si les données bancaires seraient stockées sur ses solutions.

De nombreux autres fournisseurs de solutions Cloud vont malheureusement devoir s’aligner sur les paroles de Amazon afin que les entreprises intéressées par leurs solutions connaissent les risques encourus en terme de sécurité et de normalisations.

ICANN mets un frein à la pratique du Domain Tasting

Vous avez sûrement tous déjà navigué sur des sites dédiés à la publicité jouant avec les pratiques du “Typosquatting” ou encore du “Domain Hijacking“. Une autre technique utilisée par les “domainers” (oups faut pas dire ce mots, ils aiment pas cela) se nomme le “Domain Tasting“, qui consiste à acheter un nom de domaine et tester sa popularité et sa rentabilité sur une période de 5 jours. Si le nom de domaine n’est pas populaire, donc pas rentable, au bout de 5 jours, le “domainers” pourra alors invoquer le principe “Add Grace Period” auprès de son registrar pour se faire rembourser le coût total du nom de domaine.

Ce principe de “Add Grace Period” a été mis en place par l’ICANN afin de donner une chance à l’acheteur du nom de domaine pour pouvoir se le faire rembourser en cas d’erreur dans l’orthographe du domaine.

Malheureusement, de nombreuses personnes (“domainers”) mal intentionnées ont exploités cette faille, permettant d’avoir un nom de domaine gratuit pendant 5 jours. Cette “période de grâce” leurs permettait d’enregistrer des noms de domaine en masse, de tester leurs popularités et leurs rentabilités publicitaire. Si un nom de domaine enregistré réussissait à rembourser son coût d’achat avant la période de 5 jours, celui-ci était conservé par le domainer, tous les autres domaines moins rentables étaient tous simplement rendus au “registrar” en invoquant le principe de “Add Grace Period”.

Le 17 Décembre 2008, l’ICANN ne supportant plus cette situation, le principe de “Add Grace Period” a été revu, demandant depuis au “registrar” de payer 6,75$ par nom de domaine qui ne serait pas conservé. Le “registrar” bien sûr a répercuter ce coût sur les “domainers” et tous naturellement la technique de “Domain Tasting” c’est réduite de 99.7% !!! Comme quoi l’argent, c’est le nerf de la guerre

Fping à la découverte d’hôtes

Quoi de mieux que la bonne commande “ping” pour découvrir si des hôtes répondent présents ou non dans un réseau. Mais si nous avons plusieurs centaines de machines à vérifier, et/ou si un Firewall détecte les comportements de ping d’une adresse IP les unes après les autres, la mission de reconnaissance devient longue et fastidieuse.

Afin de palier au manque de la commande “ping” classique, l’outil fping permet de fournir en entrée une liste de plusieurs hôtes, ou réseaux, à analyser. Et à la place d’attendre la réponse d’un hôte pour commencer le test suivant, fping passera à un hôte suivant sélectionné dans la liste fournie en entrée et cela de façon aléatoire.

  • Ping sur un hôte

xxxx@xxxx $ sudo fping xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx is unreachable

  • Ping sur plusieurs hôtes

xxxxx@xxxxx $ sudo fping xxx.xxx.xxxx.xxx yyy.yyy.yyy.yyy
yyy.yyy.yyy.yyy is alive
xxx.xxx.xxx.xxx is unreachable

  • Ping sur plusieurs hôtes fournis dans un fichier

xxxx@xxxxx $ cat hosts.txt
xxx.xxx.xxx.xxx
yyy.yyy.yyy.yyy

xxxxx@xxxx $ sudo fping -f hosts.txt
yyy.yyy.yyy.yyy is alive
xxx.xxx.xxx.xxx is unreachable

  • Ping sur un réseau ou un nombre déterminé de hôtes

xxxxx@xxxxxx $ sudo fping -g xxx.xxx.xxx.0/24

xxxxx@xxxxxx $ sudo fping -g xxx.xxx.xxx.8 xxx.xxx.xxx.15

Il n’est pas possible de spécifier plusieurs réseaux les uns à la suite des autres, ni même de les appeler par l’option “-f

  • Afficher le temps de réponse au ping

xxxxx@xxxx $ sudo fping -e yyy.yyy.yyy.yyy
yyy.yyy.yyy.yyy is alive (128 ms)

  • Afficher la résolution de l’adresse IP

xxxx@xxxx $ sudo fping -n yyy.yyy.yyy.yyy
toto.toto.com is alive

  • Afficher l’IP et la résolution de l’adresse IP

xxxx@xxxx $ sudo fping -n -A yyy.yyy.yyy.yyy
toto.toto.com (yyy.yyy.yyy.yyy) is alive

  • Afficher les statistiques finale

xxxxx@xxxxx $ sudo fping -s xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
yyy.yyy.yyy.yyy is alive
xxx.xxx.xxx.xxx is unreachable

2 targets
1 alive
1 unreachable
0 unknown addresses

4 timeouts (waiting for response)
5 ICMP Echos sent
1 ICMP Echo Replies received
0 other ICMP received

23.3 ms (min round trip time)
23.3 ms (avg round trip time)
23.3 ms (max round trip time)
4.087 sec (elapsed real time)

  • N’afficher que les hôtes qui répondent

xxxx@xxxx $ sudo fping -a xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
yyy.yyy.yyy.yyy

  • N’afficher que les hôtes qui ne répondent pas

xxxx@xxxxx $ sudo fping -u xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
xxx.xxx.xxx.xxx

  • Ping fping versus ping nmap

Nmap propose aussi une option ping pour vérifier si un hôte est accessible ou pas (-sP). A la différence de fping (qui effectue uniquement une demande “ICMP echo request“, nmap va lancer une connexion ACK sur le port 80 de l’adresse IP, et demandera aussi un “ICMP echo request“. L’option “-sP” de nmap n’est pas un véritable ping, mais permet éventuellement d’aller un peu plus loin dans l’étude de disponibilité d’un hôte ou pas.

Prenons, par exemple, notre machine xxx.xxx.xxx.xxx qui ne répond pas avec fping, et lançons l’analyse avec nmap.

xxxxx@xxxxxx $ sudo nmap -v -sP xxx.xxx.xxx.xxx

Starting Nmap 4.76 ( http://nmap.org ) at 2009-06-28 11:09 CEST
Initiating Ping Scan at 11:09
Scanning xxx.xxx.xxx.xxx [2 ports]
Completed Ping Scan at 11:09, 0.08s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:09
Completed Parallel DNS resolution of 1 host. at 11:09, 0.00s elapsed
Host toto.titi.com (xxx.xxx.xxx.xxx) appears to be up.
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds
Raw packets sent: 2 (68B) | Rcvd: 1 (40B)

Un tcpdump nous permet de voir ce qui se passe lorsque nmap -sP est lancé.

10:17:19.259833 IP 192.168.aaa.aaa.50409 > xxx.xxx.xxx.xxx.80: . ack 2315653060 win 3072
10:17:19.260143 IP 192.168.aaa.aaa > xxx.xxx.xxx.xxx: ICMP echo request, id 21709, seq 0, length 8
10:17:19.283920 IP xxx.xxx.xxx.xxx.80 > 192.168.aaa.aaa.50409: R 2315653060:2315653060(0) win 0

Le hôte ne répond pas à la connexion “ICMP echo request”, mais par contre répond sur le port 80. Ce fait peut être vérifié par un simple telnet.

xxxxx@xxxxxx $ telnet xxx.xxx.xxx.xxx 80
Trying xxx.xxx.xxx.xxx...
telnet: connect to address xxx.xxx.xxx.xxx: Connection refused
telnet: Unable to connect to remote host

L’on peut remarquer que le port 80 est ouvert, mais filtré par des règles quelconques.

  • Détection de filtrage par le biais de fping, versus nmap

Fping pourra permettre par les réponses données, de voir que certains hôtes sont inaccessible à cause de règles quelconques, petits exemples :

Exemple 1 :

xxxxxx@xxxxx $ sudo fping zzz.zzz.zzz.zzz
ICMP Unreachable (Communication Administratively Prohibited) from zzz.zzz.zzz.zzz for ICMP Echo sent to zzz.zzz.zzz.zzz
ICMP Unreachable (Communication Administratively Prohibited) from zzz.zzz.zzz.zzz for ICMP Echo sent to zzz.zzz.zzz.zzz
ICMP Unreachable (Communication Administratively Prohibited) from zzz.zzz.zzz.zzz for ICMP Echo sent to zzz.zzz.zzz.zzz
ICMP Unreachable (Communication Administratively Prohibited) from zzz.zzz.zzz.zzz for ICMP Echo sent to zzz.zzz.zzz.zzz
zzz.zzz.zzz.zzz is unreachable

L’hôte sera déclaré comme “unreachable”, par contre les messages de retour montre qu’un élément filtrant empêche la communication.

Comparons maintenant ces résultats avec l’option “-sP” de nmap.

xxxx@xxxxx $ sudo nmap -v -sP zzz.zzz.zzz.zzz

Starting Nmap 4.76 ( http://nmap.org ) at 2009-06-28 11:20 CEST
Initiating Ping Scan at 11:20
Scanning zzz.zzz.zzz.zzz [2 ports]
Completed Ping Scan at 11:20, 0.08s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:20
Completed Parallel DNS resolution of 1 host. at 11:20, 0.02s elapsed
Host yaya.gougou.com (zzz.zzz.zzz.zzz) appears to be up.
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds
Raw packets sent: 2 (68B) | Rcvd: 1 (56B)

Nmap a déclaré que l’hôte était accessible, car le port 80 de cette machine est accessible, mais par contre ne nous a pas donner autant d’information sur fping sur la présence d’un élément filtrant. Il faudra rajouter l’option “-d” ou “–packet-trace” pour avoir le même résultat que fping.

Exemple 2 :

xxxxx@xxxxx $ sudo fping rrr.rrr.rrr.rrr
ICMP Host Unreachable from sss.sss.sss.sss for ICMP Echo sent to rrr.rrr.rrr.rrr
ICMP Host Unreachable from sss.sss.sss.sss for ICMP Echo sent to rrr.rrr.rrr.rrr
ICMP Host Unreachable from sss.sss.sss.sss for ICMP Echo sent to rrr.rrr.rrr.rrr
rrr.rrr.rrr.rrr is unreachable

L’on peut voir grâce à fping que l’hôte sss.sss.sss.sss répond lorsque l’on effectue un ping sur l’hôte rrr.rrr.rrr.rrr

Comparons maintenant ces résultats avec l’option “-sP” de nmap.

xxxxx@xxxxx $ sudo nmap -v -sP rrr.rrr.rrr.rrr

Starting Nmap 4.76 ( http://nmap.org ) at 2009-06-28 11:29 CEST
Initiating Ping Scan at 11:29
Scanning rrr.rrr.rrr.rrr [2 ports]
Completed Ping Scan at 11:29, 3.03s elapsed (1 total hosts)
Host rrr.rrr.rrr.rrr appears to be down.
Read data files from: /usr/local/share/nmap
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.57 seconds
Raw packets sent: 4 (136B) | Rcvd: 0 (0B)

L’on peut voir ici que nmap ne nous signifie pas que l’hôte sss.sss.sss.sss répond lorsque l’on effectue un ping sur l’hôte rrr.rrr.rrr.rrr

L’option “-PN” pourra détecter que l’hôte rrr.rrr.rrr.rrr est up, mais sans pour autant nous signifier que sss.sss.sss.sss est un élément intermédiaire de filtrage.

Fping est un outil de base, qui en complément avec d’autres outils, tels que nmap, pourrait permettre d’avoir une vue complète sur un réseau et effectuer une phase d’approche intéressante.