Abstract
Une fois le réseau installé et configuré, celui-ci ne va cesser
d'évoluer. De nouveaux systèmes viennent s'y ajouter, de vieilles et
fidèles machines disparaissent, bref, tout change tout le temps. Les
utilisateurs peuvent également agir dans le dos de l'administrateur et
apporter leurs propres modifications au réseau.
Pour vérifier l'état de son réseau, un administrateur doit se
comporter comme un pirate et tenter de pénétrer ses propres
défenses. Cet article présente la démarche à suivre.
Introduction
Il est important de tester la sécurité de son propre réseau en
se mettant à la place du pirate pour découvrir d'éventuelles
failles. Ces tests se décomposent en plusieurs étapes :
- phase d'approche : récupération d'informations sur le
réseau cible ;
- phase d'analyse : détermination, à l'aide des résultats obtenus à
l'étape précédente, des vulnérabilités potentielles et des
outils nécessaires à leur exploitation ;
- phase d'attaques : passage à l'acte.
Avant d'entreprendre la dernière étape, l'administrateur du réseau
doit impérativement vous avoir donné son consentement, et pas
uniquement oral. Le chapitre III du code pénal traite des
atteintes aux systèmes de traitement automatisé de données. On y
trouve 7 articles, dont voici les trois premiers :
- Article 323-1 :
Le fait d'accéder ou de se maintenir, frauduleusement, dans tout
ou partie d'un système de traitement automatisé de données est
puni d'un an d'emprisonnement et de 100 000 F
d'amende.
Lorsqu'il en est résulté soit la suppression ou la modification
de données contenues dans le système, soit une altération du
fonctionnement de ce système, la peine est de deux ans
d'emprisonnement et de 200 000 F d'amende.
- Article 323-2 :
Le fait d'entraver ou de fausser le fonctionnement d'un système de
traitement automatisé de données est puni de trois ans
d'emprisonnement et de 300 000 F d'amende.
- Article 323-3 :
Le fait d'introduire frauduleusement des données dans un système
de traitement automatisé ou de supprimer ou de modifier
frauduleusement les données qu'il contient est puni de trois ans
d'emprisonnement et de 300 000 F d'amende.
Le 323-1 concerne l'intrusion en elle-même. Lorsque que, de plus,
elle induit des altérations des données du système, la peine est
majorée. Le 323-2 porte sur des nuisances faites au réseau (virus,
mail bombing, DoS, ...). Enfin, le 323-3 punit les modifications
faites volontairement aux données présentes sur le réseaux (comprendre
par "données" aussi bien les meilleurs scores à xbill que les fichiers
de configuration du réseau).
Mettre à l'épreuve la sécurité d'un réseau signifie en général
"résistance aux menaces externes". Cependant, de nombreuses opérations
malveillantes sont facilement menées depuis une machine du réseau
lui-même (virus, backdoor, sniffer...). Ces sources de danger sont
rarement prises en considération lors de l'évaluation du réseau. De
même, la plupart des attaques présentées dans l'article d'Éric
Detoisien doivent également être évaluées (spoofing, (D)Dos...).
Des scénarii variés sont envisageables en guise de tests
d'intrusion :
- le testeur ne connaît rien du réseau cible et ne dispose d'aucun
accès à celui-ci, nous sommes dans le cas d'un test d'intrusion
externe ;
- le testeur dispose de privilèges minimaux sur le réseau cible
(compte utilisateur quelconque). Il cherche à accroître ses
privilèges depuis l'intérieur même du réseau (écrans de veille
non activés, sniffing, exploitation de vulnérabilités
locales..). Dans ce cas, il s'agit d'un test d'intrusion interne.
Les résultats obtenus doivent permettre de mieux cerner, afin de
les corriger, les problèmes potentiels ou existants sur le réseau
cible. Par exemple, il faut évaluer le comportement de
l'administrateur face aux tentatives d'intrusion ou à l'intrusion
elle-même si elle réussit (sera-t-elle détectée ? Au bout de combien
de temps ? ...)
La guerre de l'information
Nous nous plaçons donc dans la peau d'une personne qui cherche à
récolter un maximum de renseignements sur un réseau cible. Cette
collecte se divise en deux étapes. Dans un premier temps, nous allons
récupérer toutes les informations disponibles sans accéder directement
aux ressources de la cible. Ensuite, lorsque nous commencerons à avoir
une idée plus précise de ce dont il retourne, nous accéderons
directement aux moyens fournis par la cible.
Les requêtes indirectes
Dans cette catégorie, nous plaçons tous les moyens qui permettent
d'en apprendre plus sur la cible, mais sans la contacter
directement. Ces informations sont disponibles, il suffit de savoir où
chercher.
Interrogation des bases whois
Les serveurs whois, aussi appelés
nicname (port 43), permettent d'accéder à la base de
données des renseignements fournis lors de l'enregistrement d'un nom
de domaine :
- des informations administratives comme des noms, téléphones et
adresses pour différents contacts (
admin-c,
tech-c, zone-c,
bill-c...) ;
- des informations techniques telles que le(s) nom(s) du(des) DNS(s),
les adresses emails des responsables évoqués ci-dessus, les ensembles
d'adresses IP alloués à la cible...
Cette base de données, autrefois gérée par InterNIC et maintenant
par Network Solutions, reste simplement accessible à tous car elle
permet de vérifier si un nom de domaine existe déjà.
Les sociétés qui enregistrent les noms de domaine offrent
généralement un service d'interrogation en ligne (voir le tableau 1). Sous Unix, il existe également la commande
whois.
| AFNIC |
Association Française pour le Nommage Internet en Coopération |
www.nic.fr/cgi-bin/whois |
tous les ".fr" |
| RIPE |
Réseau IP Européen |
www.ripe.net/cgi-bin/whois |
couvre l'Europe, le Moyen-Orient et quelques pays d'Asie et d'Afrique
|
| InterNIC |
Pris sur leur page web : "InterNIC is a registered service mark
of the U.S. Department of Commerce. This site is being hosted by
ICANN on behalf of the U.S. Department of Commerce". |
www.internic.net/whois.html |
les ".com", ".net", ".edu" et autres ".org" |
Tab. 1 : bases whois
Pour vous montrer la richesses des inforamtions contenues dans ce
type de base, rien de tel qu'un petit exemple sur un nom de domaine
(fictif pour des raisons de confidentialité) :
[root@testeur -> ~]$ whois pigeons.fr@whois.nic.fr
[whois.nic.fr]
Tous droits reserves par copyright.
Voir http://www.nic.fr/outils/dbcopyright.html
Rights restricted by copyright.
See http://www.nic.fr/outils/dbcopyright.html
domain: pigeons.fr
descr: PIGEON ET CIE
descr: 10 RUE DE PARIS
descr: 75001 Paris
admin-c: BPxxx-FRNIC
tech-c: LPxxx-FRNIC
zone-c: CPxxx-FRNIC
nserver: ns1.pigeons.fr
nserver: ns2.pigeons.fr
nserver: ns.heberge.fr
mnt-by: FR-NIC-MNT
mnt-lower: FR-NIC-MNT
changed: frnic-dbm-updates@nic.fr 20001229
source: FRNIC
role: HEBERGE Hostmaster
address: Heberge Telecom
address: 10 rue de Gennevilliers
address: 92230 Gennevilliers
phone: +33 1 41 00 00 00
fax-no: +33 1 41 00 00 01
e-mail: hostmaster@heberge.fr
admin-c: AAxxx-FRNIC
tech-c: BBxxx-FRNIC
nic-hdl: CCxxx-FRNIC
notify: hm-dbm-msgs@ripe.net
mnt-by: HEBERGE-NOC
changed: hostmaster@heberge.fr 20000814
changed: migration-dbm@nic.fr 20001015
source: FRNIC
person: Bernard Pigeon
address: PIGEON ET CIE
address: 10 RUE DE PARIS
address: 75001 Paris
address: France
phone: +33 1 53 00 00 00
fax-no: +33 1 53 00 00 01
e-mail: bernard.pigeon@pigeons.fr
nic-hdl: BPxxxx-FRNIC
notify: bernard.pigeon@pigeons.fr
mnt-by: HEBERGE-NOC
changed: bernard.pigeon@pigeons.fr 20001228
source: FRNIC
person: Luc Pigeon
address: PIGEON ET CIE
address: 10 RUE DE PARIS
address: 75001 Paris
address: France
phone: +33 1 53 00 00 00
fax-no: +33 1 53 00 00 01
e-mail: luc.pigeon@pigeons.fr
nic-hdl: LPxxx-FRNIC
mnt-by: HEBERGE-NOC
changed: aaa@heberge.fr 20001228
source: FRNIC
Nous apprenons que la société Pigeon et Cie est en fait
hébergée par Heberge Telecom. Les adresses emails
correspondent sans doute à des alias, mais elles nous fournissent
également une piste sur l'existence de comptes sur des machines :
si les mots de passe correspondant sont faibles (comme les prénoms,
dates de naissance...), cette information peut se révéler utile.
Toujours via les bases whois des recherches plus poussées à partir
d'une adresse IP appartenant à la société Pigeon et Cie nous
amènent à découvrir les classes d'adresses IP qui lui ont été
allouées. Pour cela, nous utilisons la base whois de RIPE qui se
révèle être la plus pertinente :
[root@testeur -> ~]$ whois 10.51.23.246@whois.ripe.net
% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit http://www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html
inetnum: 10.51.23..0 - 10.51.23.255
netname: PIGEON-CIE
descr: Pigeon et Cie
country: FR
admin-c: OMxxxx-RIPE
tech-c: OMxxxx-RIPE
status: ASSIGNED PA
notify: admin@pigeons.fr
mnt-by: PC-XXX
changed: admin@pigeons.fr 20000223
source: RIPE
En outre, des recherches croisées sur les noms récupérés peuvent
nous donner des informations supplémentaires sur la cible (découvrir
de nouvelles adresses IP ou de nouveaux serveurs DNS).
Le bilan des recherches via les bases whois est très concluant
puisque nous avons récupéré :
- les serveurs DNS ayant autorité sur le domaine
pigeons.fr ;
- les coordonnées des contacts administratifs et techniques
liés à Pigeon et Cie ;
- les classes d'adresses IP alloués à la société Pigeon et
Cie.
Nous pouvons tout de même continuer à glaner des informations sur
Internet.
News Group
Souvent les administrateurs ou les développeurs se retrouvent face
à des problèmes. Pour les résoudre, ils utilisent les NewsGroup pour
poser des questions. Malheureusement, ils donnent souvent beaucoup
trop d'informations sur leur système d'information (technologie,
version des applications utilisées, fragment de code...). Pour faire
des recherches, nous pouvons demander à groups.google.com
avec comme critère de recherche @pigeons.fr par
exemple. Ce moteur, très performant, remonte alors tous les messages
postés par des personnes de la société Pigeon et Cie. Outre
les informations techniques, nous pouvons obtenir des renseignements
sur les goûts personnels de certaines personnes de la société. Ces
indications servirons lors de recherche de mots de passe ou pour
améliorer une éventuelle tentative Social Engineering (expliqué
ultérieurement).
Moteur de recherche
Même principe que pour les NewsGroup, nous essayons de récupérer
d'autres données sur le système d'information cible en utilisant un
moteur de recherche. Dès lors, les mots clés employer ne seront
limités que par notre imagination. Là encore,
www.google.com est très performant surtout grâce à son
cache. Néanmoins, des méta-moteurs comme www.dogpile.com
donnent des résultats pertinents en multipliant les recherches sur
plusieurs moteurs.
Social Engineering
Nous sortons un peu des requêtes indirectes puisque cette
technique implique un contact direct avec la cible. Néanmoins, cette
démarche n'est toujours pas technique c'est pourquoi elle ne fait pas
partie des requêtes directes. Le social engineering se pratique pour
obtenir des informations confidentielles (mot de passe, renseignements
techniques, numéro de téléphone, adresse IP...) des utilisateurs du
système d'information cible. Tous les moyens possibles et imaginables
sont à disposition (téléphone, mail, fax...). Avec une usurpation
d'identité et une exploitation habile des informations récoltées au
préalable sur les personnes et la société, la crédibilité est au
rendez-vous ainsi que de précieuses données.
Divers
Les requêtes indirectes sont quasiment illimités, un pirate a le
temps pour lui, il ira jetter un oeil sur le site de la société ou de
ces filiales. D'autres données sur les sociétés et sur les marques se
retrouvent sur des sites comme www.societe.com ou celui
des pages jaunes (les numéros de téléphone ou des noms de
personnes). Les résultats dépendent evidemment de l'inventivité du
pirate.
Les requêtes directes
Les informations récupérées jusqu'ici ne proviennent pas
directement de la cible. Nous allons maintenant lancer quelques sondes
dans sa direction et voir tout ce que nous pouvons récupérer.
Du point de vue de la cible, nous verrons également comment
déjouer certaine interrogation. A la différence des étapes
précédentes, la cible contrôle maintenant les données que le testeur
recherche. C'est donc à elle de faire en sorte de les limiter au
minimum.
Interrogation des DNS
La requête whois nous montre les DNSs utilisés. Que
peuvent nous révéler ces derniers ?
Pour obtenir des
informations de ces serveurs, il suffit de les interroger dans un
langage qu'ils comprennent à savoir le protocole DNS. Plusieurs
requêtes sont à notre disposition :
- Récupération de tous les serveurs DNS ayant autorités sur le domaine
[root@testeur -> ~]$ host -v -t ns pigeons.fr ns1.pigeons.fr
Using domain server:
Name: ns1.pigeons.fr
Address: 10.250.149.163
Aliases:
Trying null domain
rcode = 0 (Success), ancount=3
The following answer is not verified as authentic by the server:
pigeons.fr 172800 IN NS ns1.pigeons.fr
pigeons.fr 172800 IN NS ns2.pigeons.fr
pigeons.fr 172800 IN NS ns.heberge.fr
Additional information:
ns1.pigeons.fr 172800 IN A 10.250.149.163
ns2.pigeons.fr 172800 IN A 10.250.149.165
ns.heberge.fr 345317 IN A 10.51.3.65
Nous avons donc la confirmation des serveurs DNS utilisés ainsi
que leur adresse IP.
- Récupération des serveurs de messagerie (Mail eXchanger) du domaine
[root@testeur -> ~]$ host -v -t mx pigeons.fr ns1.pigeons.fr
Using domain server:
Name: ns1.pigeons.fr
Address: 10.250.149.163
Aliases:
Trying null domain
rcode = 0 (Success), ancount=1
The following answer is not verified as authentic by the server:
pigeons.fr 172800 IN MX 0 smtp1.pigeons.fr
For authoritative answers, see:
pigeons.fr 172800 IN NS ns1.pigeons.fr
pigeons.fr 172800 IN NS ns2.pigeons.fr
pigeons.fr 172800 IN NS ns.heberge.fr
Additional information:
smtp1.pigeons.fr 172800 IN A 10.250.149.35
ns1.pigeons.fr 172800 IN A 10.250.149.163
ns2.pigeons.fr 172800 IN A 10.250.149.165
ns.heberge.fr 345239 IN A 10.51.3.65
- Vérification des deux requêtes précédentes
[root@testeur -> ~]$ host -a pigeons.fr ns1.pigeons.fr
Using domain server:
Name: ns1.pigeons.fr
Address: 10.250.149.163
Aliases:
Trying null domain
rcode = 0 (Success), ancount=5
The following answer is not verified as authentic by the server:
pigeons.fr 172800 IN NS ns1.pigeons.fr
pigeons.fr 172800 IN SOA ns1.pigeons.fr dnsmaster.pigeons.fr(
2000060601 ;;serial (version)
21600 ;refresh period
3600 ;retry refresh this often
3600000 ;expiration period
172800 ;minimum TTL
)
pigeons.fr 172800 IN NS ns2.pigeons.fr
pigeons.fr 172800 IN NS ns.heberge.com
pigeons.fr 172800 IN MX 0 smtp1.pigeons.fr
For authoritative answers, see:
pigeons.fr 172800 IN NS ns1.pigeons.fr
pigeons.fr 172800 IN NS ns2.pigeons.fr
pigeons.fr 172800 IN NS ns.heberge.fr
Additional information:
ns1.pigeons.fr 172800 IN A 10.250.149.163
ns2.pigeons.fr 172800 IN A 10.250.149.165
ns.heberge.fr 345225 IN A 10.51.3.65
smtp1.pigeons.fr 172800 IN A 10.250.149.35
Désormais nous avons toutes les informations que nous pouvions
recupérer facilement et à tous les coups. Explorons plus avant le
domaine pigeons.fr en recherchant des informations sur
les machines présentes sur le réseau :
- Le transfert de zone renvoie toute la configuration du serveur DNS
[root@testeur -> ~]$ host -l pigeons.fr ns1.pigeons.fr
Using domain server:
Name: ns1.pigeons.fr
Address: 10.250.149.163
Aliases:
pigeons.fr name server ns1.pigeons.fr
pigeons.fr name server ns2.pigeons.fr
pigeons.fr name server ns.heberge.fr
m01.pigeons.fr has address 10.51.23.226
m02.pigeons.fr has address 10.51.23.227
www2.pigeons.fr has address 10.51.23.247
m03.pigeons.fr has address 10.51.23.228
m04.pigeons.fr has address 10.51.23.229
m05.pigeons.fr has address 10.51.23.230
m10.pigeons.fr has address 10.51.23.238
m09.pigeons.fr has address 10.51.23.237
m12.pigeons.fr has address 10.250.149.162
m13.pigeons.fr has address 10.250.149.163
m14.pigeons.fr has address 10.250.149.165
m16.pigeons.fr has address 10.51.23.251
m39.pigeons.fr has address 10.51.23.249
w3.pigeons.fr has address 10.101.154.68
w5.pigeons.fr has address 10.101.154.67
w7.pigeons.fr has address 10.101.154.73
w8.pigeons.fr has address 10.101.154.77
w9.pigeons.fr has address 10.101.154.79
w5-private.pigeons.fr has address 10.101.154.70
w3-ccc.pigeons.fr has address 10.101.154.72
w3-bbb.pigeons.fr has address 10.101.154.71
www.pigeons.fr has address 10.51.23.246
La chance est avec nous, une mauvaise configuration nous a
permis de lister toutes les machines du domaine
pigeons.fr. Dans le cas contraire, nous aurions
refait la même opération sur les autres serveurs DNS car
souvent le serveur principale est bien configuré contrairement
aux autres.
- D'autres tests sont intéressants quand le transfert de
zone est impossible. Par exemple, nous pouvons regarder s'il
est possible de récupérer l'adressage interne.
[root@testeur -> ~]$ host -a 0.168.192.in-addr.arpa ns1.pigeon2.com
Using domain server:
Name: ns1.pigeons2.fr
Address: 10.81.144.121
Aliases:
Trying null domain
rcode = 0 (Success), ancount=4
The following answer is not verified as authentic by the server:
0.168.192.in-addr.arpa 3600 IN NS server2.pigeons2.fr
0.168.192.in-addr.arpa 3600 IN NS server1.pigeons2.fr
0.168.192.in-addr.arpa 3600 IN NS echange.pigeons2.fr
0.168.192.in-addr.arpa 3600 IN SOA server1.pigeons2.fr root.pigeons2.fr(
585 ;serial (version)
900 ;refresh period
600 ;retry refresh this often
86400 ;expiration period
3600 ;minimum TTL
)
Additional information:
server2.pigeons2.fr 3600 IN A 192.168.0.1
server1.pigeons2.fr 3600 IN A 192.168.0.2
server1.pigeons2.fr 3600 IN A 10.81.144.121
echange.pigeons2.fr 3600 IN A 192.168.0.3
Nous avons pris ici une autre cible puisque le transfert de zone
précédent nous a montré aucune machine avec un adressage privé
(192.168.0.1 par exemple). Nous voyons donc que la zone
0.168.192.in-addr.arpa est gérée par le serveur DNS
ns1.pigeons2.fr. Il suffit donc de tester toutes
les machines du réseau 192.168.0.*.
[root@testeur -> ~]$ host 192.168.0.1 ns1.pigeons2.fr
1.0.168.192.IN-ADDR.ARPA 1200 IN PTR server1.pigeons2.fr
Il ne reste plus qu'à créer un petit script (en Perl par
exemple) qui répète cette commande pour les adresses de
192.168.0.1 à 192.168.0.254.
- Enfin, dans le cas d'un Bind uniquement, nous pouvons obtenir
sa version, ce qui est très intéressant quand on connaît le long
passé de ce serveur en terme d'exploits à distance.
[root@testeur -> ~]$ nslookup
Default Server: ns1.pigeons.fr
Address: 10.250.149.163
> set class=chaos
> set query=txt
> version.bind
Server: ns1.pigeons.fr
Address: 10.250.149.163
VERSION.BIND text = "8.2.3-REL"
Nous obtenons bien la version de Bind, ce qui pourra nous
permettre de trouver une éventuelle vulnérabilité sur cette
version (un buffer overflow par exemple).
Utilisation de ping
Les requêtes indirectes (whois) et l'interrogation des DNS nous
ont permis de récupérer des adresses IP et des classes d'adresses IP
appartenant à la cible. En effectuant, un ping sur chacune de ces
adresses IP, nous allons savoir lesquelles sont accessibles. Il faut
néanmoins prendre en compte le fait que la présence d'un firewall peut
empécher la machine de répondre au ping. Le scan de port solutionnera
se problème en détectant la présence de la machine dans le cas où elle
a un port ouvert. Nmap effectue très bien cette tâche :
[root@testeur -> ~]$ nmap -sP 10.51.23.* -n
Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ )
Host (10.51.23.226) appears to be up.
Host (10.51.23.227) appears to be up.
Host (10.51.23.228) appears to be up.
Host (10.51.23.229) appears to be up.
Host (10.51.23.230) appears to be up.
Host (10.51.23.237) appears to be up.
Host (10.51.23.238) appears to be up.
Host (10.51.23.246) appears to be up.
Host (10.51.23.247) appears to be up.
Host (10.51.23.249) appears to be up.
Host (10.51.23.251) appears to be up.
Nmap run completed -- 256 IP addresses (11 hosts up) scanned in 2 seconds
Utilisation de traceroute
Le but du jeu est d'obtenir l'adresse IP d'un routeur d'accès aux
machines cibles. Pour cela, il suffit de faire un traceroute en
direction d'une machine du réseau cible :
[root@testeur -> ~]$ traceroute 10.51.23.251
traceroute 10.101.154.70
1 10.0.0.1 1.612 ms 1.443 ms 1.532 ms
2 10.18.23.5 5.790 ms 5.454 ms 5.536 ms
3 10.20.20.1 5.605 ms 5.453 ms 5.338 ms
4 10.51.15.1 6.805 ms 6.437 ms 6.552 ms
5 10.51.192.7 7.783 ms 7.246 ms 7.329 ms
6 10.51.173.65 7.402 ms 7.246 ms 7.732 ms
7 10.51.159.33 7.582 ms 7.844 ms 7.935 ms
8 10.51.23.1 8.202 ms 7.639 ms 7.909 ms
9 10.51.23.251 7.807 ms 7.633 ms 7.733 ms
La machine juste avant la destination est un routeur.
Port Scan
Il existe une grande variétés de méthodes pour scanner, dont la
description dépasse largement le cadre de cet article. Le principe
général de toute méthode de scan est d'envoyer un paquet (TCP, UDP,
ICMP...) sur la machine cible et de voir ce qui se passe. Selon la
méthode employées, le testeur détermine l'état du port (ouvert, fermé,
filtré).
Le but du scan est similaire à celui de l'éclaireur. Le testeur
(ou le pirate) détermine ainsi le rôle des machines, les services
accessibles, les protocoles supportés... A la fin de l'opération, les
informations suivantes sont obtenues :
- les adresses IP des machines du réseau ;
- la liste des services disponibles ;
- la liste des différents protocoles supportés (TCP, UDP, ICMP...)
- pour un maximum de machines, l'état de chacun de ses
ports.
Pour un administrateur, cette étape dévoile les accès à ses
machines. Il doit également installer des outils lui permettant de
détecter les scans qu'il n'a pas lui-même dilligentés
(iplog ou portsentry par exemple).
Il existe différentes solutions pour échapper à ce genre de
détecteurs, en spoofant des adresses IP ou en distribuant le scan
depuis plusieurs machines.
Par exemple, lorsque l'adresse source du paquet est spoofée, la
machine de test reste inconnue de la machine cible, bien que celle-ci
sache alors qu'elle a été scannée :
kelly (192.168.1.3) la machine de
tests bosley (192.168.1.2) une machine calme
(i.e. qui ne génère pas beaucoup de trafic) ;charly (192.168.1.1) la machine
cible.
Pour détecter si un port TCP laisse passer les paquets,
kelly envoie régulièrement des paquets à
bosley. Si bosley génère peu de trafic sur
le réseau, le champs id de ses paquets varie peu. Dans le même temps,
kelly envoie à charly des paquets TCP avec
le drapeau SYN activé (comme pour une demande de connexion normale),
mais en mettant comme adresse source celle de
bosley. Ainsi, charly répond à
bosley avec des paquets SYN-ACK si le port est
ouvert. bosley, qui n'a rien demandé, envoie un paquet
RST à charly pour couper la connexion. Du coup, le champs
id augmente puisque deux paquets sont émis (le RST et la réponse à
kelly :
[root@kelly intrusion]$ hping -r bosley
46 bytes from 192.168.1.2: flags=RA seq=1 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=2 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=3 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=4 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=5 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=6 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=7 ttl=255 id=+3 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=8 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=9 ttl=255 id=+2 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=10 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=11 ttl=255 id=+1 win=0 rtt=0.4 ms
Simultanément depuis un autre terminal :
[root@kelly intrusion]$ hping -a bosley -p 22 -S charly
eth0 default routing interface selected (according to /proc)
HPING charly (eth0 192.168.1.1): S set, 40 headers + 0 data bytes
--- charly hping statistic ---
6 packets tramitted, 0 packets received, 100% packet loss
Il est normal que kelly ne recoive aucune réponse de
charly puisqu'elles sont envoyées à bosley.
Au contraire, lorsque le port cible n'est pas ouvert,
charly n'émet aucun paquet. Le champs id ne varie alors
pas :
[root@kelly intrusion]$ hping -r bosley
..
46 bytes from 192.168.1.2: flags=RA seq=61 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=62 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=63 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=64 ttl=255 id=+1 win=0 rtt=0.3 ms
..
Le port cible (hping -a bosley -p 80 -S charly) est
donc fermé. Les logs de charly contiennent une tentative
de connexion provenant de bosley.
Pour induire un scan en erreur, il est également possible de
laisser tourner un pot de miel (honney pot). Ceci
ressemble à un serveur, a le goût d'un serveur, mais ce n'est pas un
vrai serveur :
/* fake.c : just a socket bound to a port */
#include <stdlib.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>
main(int argc,char *argv[]) {
int port; //port number
struct sockaddr_in sock; //the socket for the server
int sd; //socket descriptor
if (argc!=2) exit(EXIT_FAILURE);
port = htons(atoi(argv[1]));
if ( (sd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
perror("No socket");
exit(EXIT_FAILURE);
}
sock.sin_family = AF_INET;
sock.sin_port = port;
sock.sin_addr.s_addr = INADDR_ANY;
if (bind(sd, (struct sockaddr*)&sock, sizeof(struct sockaddr)) == -1) {
perror("can't bind");
exit(EXIT_FAILURE);
}
/* Let's go for LISTEN mode */
if (listen(sd, 2) == -1) {
perror("Bad listen");
exit(EXIT_FAILURE);
}
while(1) sleep(1);
}
Il suffit alors de le mettre sur le port de son choix :
[root@charly fake]$ gcc -o fake fake.c
[root@charly fake]$ ./fake 21 &
[2] 3373
[root@charly fake]$ lsof -ni | grep fake
fake 3373 root 3u IPv4 201230 TCP *:ftp (LISTEN)
[root@charly fake]$ nmap charly
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on charly (192.168.1.1):
(The 1538 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
6000/tcp open X11
Nous lançons notre serveur fake sur le port 21 (ftp).
lsof nous révèle bien qu'un serveur écoute sur ce port
21. Toutefois, nmap (scanner de port) se laisse abuser
car il tente juste d'ouvrir une connexion sur le port 21. Comme il
réussit, il croit que c'est bien un serveur ftp. L'illusion fonctionne
avec ce type de scanners réseau car ils ne cherchent pas réellement à
se connecter. Toute connexion plus approfondie révélera la
supercherie, à moins d'affiner le faux serveur (par exemple en
ajoutant les bannières pour simuler le service désiré). Signalons
enfin que la commande nc (netcat) produit un résultat
similaire (nc -l -p 21 pour écouter sur le port 21).
Ce genre de défense s'appelle pot de miel. Les projets
honeynets et honneypots mettent en place des réseaux, ou
des machines, destinés à attirer les pirates pour apprendre leurs
techniques.
Scanner une machine se résumé toujours à envoyer un paquet de la
machine de tests à la machine cible, indépendamment de la méthode
employée. Selon les moyens de la machine cible (i.e. la sécurité
attendue sur celle-ci), une tentative avec 2 paquets par jour suffit
pour détecter le scan. Il faut alors de gros disques et enregistrer
tous les paquets qui arrivent sur la machine pour analyser ces données
sur plusieurs jours afin de reconstituer le scan.
OS Fingerprinting
Grâce au scan du réseau cible, nous connaissons maintenant les
machines actives. Nous affinons notre connaissance en déterminant leur
système d'exploitation. Cette connaissance nous permettra, lorsque
nous aurons également déterminé la version des daemons qui attendent
sur les ports de la machine cible, de rechercher les exploits
nécessaires à nos tests d'intrusion.
Chaque OS possède sa propre conception de la gestion des
protocoles réseaux. D'une part, certains champs sont laissés à la
charge de l'OS (TTL, ToS, Win, DF...). D'autre part, même si les RFC
définissent l'essentiel, elles ne sont pas toujours scrupuleusement
respectées. De plus, si elles interdisent bien certaines
configurations de paquets, elles ne précisent toutefois pas comment y
répondre. Par exemple, que faire d'un paquet qui contient le flag 64,
non défini ? Chacun a sa solution.
valeurs par défaut dans les paquets
En récupérant des paquets émis par la cible, nous découvrons la valeur
de paramètres :
- le champs TTL (time to live) des paquets sortants ;
- la taille de la fenêtre (window) ;
- le bit DF (Don't Fragment) ;
- le champs TOS (Type Of Service).
- ...
Selon les OS, tous ces paramètres changent. Une base de données
contenant leur valeur par défaut facilite alors l'identification. Il
suffit ainsi d'envoyer des paquets différents pour tester les réponses
puis de comparer ces dernières à une base de signatures pour
identifier l'OS.
Par exemple, le champs id permet de distinguer facilement les
linux 2.2.x des 2.4.x (la commande hping -1 -c 3 émet 3
paquets de type 1 i.e. ICMP) :
[root@charly intrusion]$ uname -a
Linux charly 2.4.4 #4 Wed May 23 10:18:08 CEST 2001 i686 unknown
[root@charly intrusion]$ hping -1 -c 3 charly
28 bytes from 192.168.1.1: icmp_seq=0 ttl=255 id=0 rtt=0.4 ms
28 bytes from 192.168.1.1: icmp_seq=1 ttl=255 id=0 rt
t=0.3 ms
28 bytes from 192.168.1.1: icmp_seq=2 ttl=255 id=0 rtt=0.3 ms
...
[root@kelly intrusion]$ uname -a
Linux kelly 2.2.19ow1 #2 Mon May 21 12:29:48 CEST 2001 i686 unknown
[root@kelly intrusion]$ hping -1 -c 3 kelly
28 bytes from 128.93.24.10: icmp_seq=0 ttl=255 id=4901 rtt=0.3 ms
28 bytes from 128.93.24.10: icmp_seq=1 ttl=255 id=4903 rtt=0.2 ms
28 bytes from 128.93.24.10: icmp_seq=2 ttl=255 id=4906 rtt=0.2 ms
La pile TCP/IP
Cependant, cette méthode n'est pas très fiable car les OS
permettent souvent de modifier certaines de ces valeurs (avec
sysctl sous Linux ou dans la base de registres pour
Windows).
Une méthode plus performante consiste à analyser les réponses de
l'OS cible face à certains paquets : le testeur connaît alors le
comportement de la pile TCP/IP de la cible, ce qui est suffisant pour
identifier l'OS si les t ests sont bien choisis.
nmap (encore et toujours ;) utilise exactement cette
démarche lorsque l'option -O (OS identification) est
activée. Une base de données contient les réponses types selon les
OS. Ainsi, l'empreinte des noyaux Linux 2.4.0 - 2.4.5 correspond à
:
# Contributed by root@dexter.dynu.com
Fingerprint Linux Kernel 2.4.0 - 2.4.5 (X86)
TSeq(Class=RI%gcd=<6%SI=<2983C7E&>3DAF6%IPID=Z%TS=100HZ)
T1(DF=Y%W=16A0|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(DF=Y|N%TOS=C0|0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E|F%ULEN=134%DAT=E)
Les tests en eux-mêmes sont décrits par les lignes Ti. La
lecture de l'article de Fyodor paru dans phrack vous les détaillera
(phrack 54, fichier 9/12). Toutefois, dévoilons succinctement la
signification de chacun :
- TSeq : décrit la nature de l'incrémentation des numéros de
séquence ;
- T1 : paquet TCP avec le flag SYN|64 (comme 64 ne correspond à
aucune valeur de flag, le paquet est "syn-bogué") vers un port
ouvert ;
- T2 : paquet TCP NULL, i.e. ne contenant aucune option ni aucun
flag, vers un port ouvert ;
- T3 : paquet TCP avec les flags SYN|FIN|URG|PSH vers un port
ouvert ;
- T4 : paquet TCP avec le flag ACK vers un port ouvert ;
- T5 : paquet TCP avec le flag SYN vers un port fermé ;
- T6 : paquet TCP avec le flag ACK vers un port fermé ;
- T7 : paquet TCP avec le flag FIN|PSH|URG vers un port
fermé ;
- PU : paquet UDP envoyé à un port fermé afin de récupérer un
paquet ICMP "port unreachable".
S'il est souvent possible de modifier les valeurs de certains
paramètres, modifier le comportement complet de la pile est autrement
difficile, voire impossible avec certains OS dont les sources ne sont
pas disponibles.
Bannières
L'objectif est simple : connaître la version de l'application
utilisé pour un service spécifique. La plupart du temps, un simple
telnet sur le port désiré nous donne le
renseignement. Signalons les quelques services qui ne délivrent pas
cette information : finger (port 79), exec (port 512), login
(port 513), printer (port 515).
- FTP (port 21)
Souvent la version est dévoilée dès le login :
[root@bosley intrusion]$ telnet ftp.pigeons.fr
Trying 192.168.14.35...
Connected to ftp.pigeons.fr
Escape character is '^]'.
220 ProFTPD 1.2.0pre9 Server (ProFTPD) [ftp1-1.pigeons.fr]
Cependant, certains serveurs autorisent la dissimulation de la
bannière. La commande STAT peut nous sauver :
telnet ftp.pigeons2.fr 21
Trying 192.168.96.24...
Connected to ftp.pigeons2.fr.
Escape character is '^]'.
220 ftp.pigeons2.fr FTP server ready.
USER ftp
331 Guest login ok, send your complete e-mail address as password.
PASS raynal@home.net
230 Guest login ok, access restrictions apply.
STAT
211-ftp.pigeons2.fr FTP server status:
Version wu-2.6.1(1) Fri Feb 16 19:32:14 CET 2001
Connected to bosley (192.168.1.2)
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
144 traffic bytes received in 0 transfers
2502 traffic bytes transmitted in 0 transfers
2696 traffic bytes total in 0 transfers
211 End of status
- telnet (port 23):
Avant même que la connexion soit validée par le mot de passe, le
serveur renvoie les informations recherchées :
telnet 192.168.1.1
Trying 192.168.1.1...
Connected to charly (192.168.1.1).
Escape character is '^]'.
Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.4 on an i686
Si vous tenez vraiment à utiliser telnet, l'option
-h ne les affichera qu'une fois le client
authentifié.
- DNS (port 53) :
Nous avons vu qu'il était assez simple de récupérer la version d'un
serveur DNS. Il est cependant possible de fausser cette
information en modifiant le champs options dans
/etc/named.conf :
# /etc/named.conf
...
options {
directory "/var/named";
version "What are you doing, dude !";
};
- HTTP (port 80) :
La commande HEAD ne renvoie que les
méta-informations constituant l'en-tête HTTP :
[root@bosley intrusion]$ telnet minimum 80
Trying 192.168.1.1...
Connected to charly (192.168.1.1).
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 11 Jun 2001 19:28:57 GMT
Server: Apache/1.3.19 (Unix) (Red-Hat/Linux)
mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01
Last-Modified: Thu, 29 Mar 2001 17:53:01 GMT
ETag: "731a-b4a-3ac3767d"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html
Connection closed by foreign host.
L'ajout de la ligne ServerToken Prod limite
l'information au nom du serveur, i.e. Apache.
portmap (port 111) et les RPCs :
Comme nous le détaillons dans la suite de cet article, la
commande rpcinfo fournit toutes les versions des
services RPCs qui tournent sur la cible.
identd (port 113) :
Certaines versions supportent une extension
à la RFC 1413 : la commande VERSION :
[root@bosley intrusion]$ telnet charly 113
Connected to charly...
VERSION
0 , 0 : X-VERSION : pidentd 3.0.10 for Linux 2.2.5-22smp (Jul 20 2000 15:09:20)
Les serveurs qui supportent cette commande dispose également
souvent d'une option pour la désactiver.
Informations relatives à des protocoles spécifiques
Nous savons maintenant ce qui tourne précisément sur chacun des
systèmes (OS, serveurs, version des serveurs...). Nous continuons
notre quête de renseignements car de nombreux serveurs en dévoilent
encore beaucoup sur le réseau et ses utilisateurs :
finger fournit des informations sur les
utilisateurs du système :
[root@bosley intrusion]$ finger @charly
Login Name Tty Idle Login Time Office Office Phone
detoisien Eric Detoisien pts/7 3d Jun 5 09:47 (jil)
detoisien Eric Detoisien *pts/10 160d Jun 5 11:08 (kelly)
raynal Frederic Raynal tty1 10d May 31 09:57
raynal Frederic Raynal pts/1 3d Jun 5 09:26 (:0)
raynal Frederic Raynal pts/3 3d May 31 09:58 (:0)
raynal Frederic Raynal pts/11 3d May 31 11:52 (:0)
raynal Frederic Raynal pts/7 3d Jun 6 12:08 (:0)
raynal Frederic Raynal pts/2 Jun 10 09:35 (bosley)
root root pts/4 5d May 31 09:58
En outre, il est possible d'enchaîner les requêtes avec la
notation finger raynal@hots1@host2.
- le serveur de mails : le protocole SMTP (RFC 821) définit
les commandes VRFY et EXPN :
VERIFY (VRFY)
Cette commande demande au récepteur de confirmer que les
arguments fournis désignent bien un utilisateur. S'il s'agit
d'un nom d'utilisateur, le nom complet de ce dernier (s'il est
connu du récepteur) ainsi que la boîte aux lettres totalement
qualifiée doivent être renvoyés au requérant.
EXPAND (EXPN)
Cette commande demande au récepteur de confirmer si l'argument
associé identifie une liste de diffusion, et, si c'est le cas,
de renvoyer la liste des membres de cette liste. Le nom complet
des utilisateurs (s'il est connu) et les adresses de
boîtes-aux-lettres entièrement qualifiées seront renvoyées via
une réponse multilignes.
Sur charly, nous obtenons les informations suivantes :
vrfy root
250 system PRIVILEGED account <root@charly.pigeons.fr>
vrfy bin
250 system librarian account <bin@charly.pigeons.fr>
vrfy web
250 Web Server manager <web@charly.pigeons.fr>
vrfy ftp
550 ftp... User unknown
vrfy raynal
250 Frederic Raynal <raynal@charly.pigeons.fr>
expn pigeons
050 pigeons... aliased to detoisien, pappy, raynal
050 /home/detoisien/.forward: line 1: forwarding to detoisien@pigeons.fr
050 /home/raynal/.forward: line 1: forwarding to \raynal@charly.pigeons.fr
050 /home/raynal/.forward: line 2: forwarding to frederic.raynal@linuxmag.fr
250-Eric Detoisien <detoisien@pigeons.fr>
250-Frederic Raynal <pappy@charly.pigeons.fr>
250-Frederic Raynal <\raynal@charly.pigeons.fr>
250-Frederic Raynal <frederic.raynal@linuxmag.fr>
La plupart des serveurs SMTP permettent maintenant de les
désactiver, ce qui est donc recommandé ;)
identd (anciennement appelé auth, port
113 - RFC 1413) fournit des informations sur
l'identité des utilisateurs du système. Il dévoile le détenteur d'une
connexion, ce qui nécessite de connaître les ports cible et
destination. Pour le port cible, comme nous sommes sur notre
machine, la commande netstat -A inet nous le
révèle. Quant au port destination, nous avons déjà scanné la
machine cible ! Il ne nous reste plus qu'à nous connecter à
chacun des ports ouverts puis à demander à identd
qui est en charge de cette connexion.
Le résultat du scan de bosley est le suivant :
7/tcp open echo
22/tcp open ssh
80/tcp open http
113/tcp open auth
664/tcp open unknown
1024/tcp open kdm
1025/tcp open listen
6000/tcp open X11
Nous initialisons une connexion sur le port 113 de
bosley. Puis,
pour chacun des ports ouverts, nous nous connectons avec un simple
client telnet (telnet bosley 664). Nous
demandons alors à identd de nous donner les
informations voulues (la syntaxe des requêtes est
<port-sur-serveur>,<port-sur-client>) :
[root@charly intrusion]$ telnet bosley 113
Trying 192.168.1.2...
Connected to bosley.
Escape character is '^]'.
7,32924
7 , 32924 : USERID : OTHER :root
22,32927
22 , 32927 : USERID : OTHER :root
80,32928
80 , 32928 : ERROR : UNKNOWN-ERROR
113, 32926
113 , 32926 : USERID : OTHER :nobody
664,32930
664 , 32930 : USERID : OTHER :root
1024,32931
1024 , 32931 : USERID : OTHER :rpcuser
1025,32932
1025 , 32932 : USERID : OTHER :root
6000,32933
6000 , 32933 : USERID : OTHER :root
Connection closed by foreign host.
Nous voyons ici quelques limites à nmap. Tout
d'abord, l'erreur obtenue sur le port 80 signifie qu'en fait il
n'y a pas de serveur web sur bosley . Ensuite, le kdm
qui tourne avec l'identité rpcuser laisse plutôt
penser qu'il s'agit en fait d'un programme RPC.
Regardez attentivement les indications de configuration de votre
daemon. Il est souvent possible de remplacer le nom de l'utilisateur
par son UID, mais d'une manière générale, mieux vaut désactiver
ce serveur.
portmap (sunrpc port 111) est le
serveur essentiel au bon
fonctionnement des services qui reposent sur les RPCs (NIS,
NFS, rusers, rstat...). La commande rpcinfo révèle
ce qui tourne sur une machine :
[root@charly intrusion]$ rpcinfo -p bosley
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 661 ypbind
100007 1 udp 661 ypbind
100007 2 tcp 664 ypbind
100007 1 tcp 664 ypbind
100024 1 udp 1024 status
100024 1 tcp 1024 status
100011 1 udp 855 rquotad
100011 2 udp 855 rquotad
100005 1 udp 1025 mountd
100005 1 tcp 1025 mountd
100005 2 udp 1025 mountd
100005 2 tcp 1025 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1026 nlockmgr
100021 3 udp 1026 nlockmgr
100021 4 udp 1026 nlockmgr
390113 1 tcp 7937
rpcinfo se connecte au port 111 de la machine cible
et lui demande ce qui fonctionne dessus. portmap
n'a pas prévu de mécanismes de contrôle. Il est donc conseillé
de bloquer l'accès à se serveur via le pare-feu et le
tcp-wrapper. Dans ce cas, toutes les requêtes fondées sur les
RPC (comme les 2 suivantes) échoueront.
Cependant, l'authentification de RPCs repose sur l'adresse IP du
client. Sur un réseau local, il est très facile d'usurper une
adresse et d'accéder ainsi à tous les services RPCs
disponibles.
- Un serveur NIS contrôle les clients autorisés à l'interroger par
un mécanisme appelé securenets.
Par défaut, tout le monde peut se connecter au serveur.
N'importe quelle machine peut alors se déclarer
client de telle base NIS. Une fois connu le nom de la
base NIS (il s'agit souvent du même nom que le serveur), nous
déclarons notre machine de tests (kelly - 192.168.1.3) comme
cliente du serveur NIS (charly - 192.168.1.1) :
[raynal@kelly intrusion]$ cat /etc/yp.conf
domain charly server charly
[raynal@kelly intrusion]$ ypwhich #quel est mon serveur NIS ?
charly #bingo, il répond ;)
[raynal@kelly intrusion]$ ypcat -k passwd.byname
...
fguest fguest:B4wLh7jxO1eZA:5555:5555:Compte temporaire:/home/fguest:/bin/bash
raynal raynal:YP5.ojuxdA/6.:10943:21196:Frederic Raynal:/home/raynal:/bin/bash
...
[raynal@kelly intrusion]$ ypcat -k netgroup
angels (charly,,) (bosley,,) (kelly,,) (jil,,) (sabrina,,)
- Lorsque la machine cible exporte des répertoires par NFS, il est
parfois possible de les connaître en utilisant la commande
showmount :
[raynal@kelly intrusion]$ showmount -e charly
/var/spool/mail angels
/home/web/www (everyone)
/home angels
/opt/download jil
Nous retrouvons ici le netgroup angels découvert
précédemment dans la base NIS. Les répertoires exportés à tout
le monde (signalés par (everyone)) sont alors
accessibles sur la machine tests par
mount -t nfs <cible>:<répertoire> /mnt/cible.
- Toujours parmi les RPC, voici quelques serveurs moins
courants :
ruserd révèle les
utilisateurs connectés sur une machine :
[raynal@kelly intrusion]$ rusers -l charly
raynal charly:tty1 Jun 16 18:11 :51
raynal charly:pts/ Jun 16 18:11 (:0)
raynal charly:pts/ Jun 16 18:11 :19 (:0)
raynal charly:pts/ Jun 16 18:11 :06 (:0)
raynal charly:pts/ Jun 16 18:11 :20 (:0)
raynal charly:pts/ Jun 16 18:59 :03 (bosley)
On apprend ainsi les dates de connexion et leur
provenance.
rstatd génère des statistiques sur le
système, lues par la commande rup :
[raynal@kelly intrusion]$ rup -d charly
charly 19:15pm up 1:05, load average: 0.09 0.14 0.13
Envoie de mail
L'en-tête d'un mail fourmille d'informations pertinentes comme la
version du serveur smtp utilisé voir l'adressage interne. Nous
obtenons le chemin emprunté par le mail.
Received: from smtp1.pigeons.fr ([xxx.xxx.xxx.xxx])
by front.testeur.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA00632
for <detoisien@testeur.fr>; Wed, 18 Apr 2001 14:18:11 +0200 (MET DST)
Received: from bpigeon ([10.33.11.153]) by smtp1.pigeons.fr
(Netscape Messaging Server 3.6) with SMTP id AAA3A01
for <detoisien@testeur.fr>; Wed, 18 Apr 2001 14:14:50 +0200
Message-ID: <004401c0c801$319eff40$990b210a@sit.fr>
From: "Bernard Pigeon" bernard.pigeon@pigeons.fr
To: detoisien@testeur.fr
Subject: Test
Date: Wed, 18 Apr 2001 14:15:01 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Nous récupérons le nom et l'adresse d'une machine interne, la
version du serveur SMTP ainsi que la version du client SMTP
utilisé. Il est fréquent d'envoyer un mail à un adresse
inexistante. Ainsi, le serveur SMTP de la cible renvoie
automatiquement une réponse avec la plupart des informations
Scan CGI
L'installation par défaut d'un serveur Web et/ou une mauvaise
configuration font que de nombreux scripts peuvent être présent sur un
serveur Web. Un nombre important de ces scripts sont la source de
failles. Un scanner de CGI permet de tester la présence de ces scripts
sur un serveur cible. Le pirate pourra ainsi les utiliser pour
attaquer la machine cible. Le scanner le plus connu est
whisker.
[root@testeur -> ~]$ perl whisker.pl -h www.pigeons.fr -i
-- whisker / v1.3.0a / rain forest puppy / ADM / wiretrip --
= - = - = - = - = - =
= Host: www.pigeons.fr
- Directory index: /
= Server: Microsoft-IIS/4.0
- Appending ::, %2E, or 0x81 to URLs may give script source
- Requesting a bogus .pl may give physical path like .idc bug does
- if perl is installed
- Security settings on directories can be bypassed if you use 8.3
- Warning: Syntax Error: names
- http://www.securityfocus.com/templates/archive.pike?list=1
- &date=1999-08-15&msg=37B5D87E.D6600553@urban-a.net
- Content-Location: http://10.51.23.246/cfdocs/index.htm
+ 200 OK: GET /cfdocs/cfmlsyntaxcheck.cfm
+ 200 OK: GET /cfide/Administrator/startstop.html
- can start/stop the server...w00h00
+ 200 OK: HEAD /iisadmpwd/aexp4b.htr
- gives domain/system name
+ 200 OK: HEAD /msadc/msadcs.dll
- RDS. See RDS advisory, RDP9902
- Need I remind you, do not abuse, kids?
Nous avons une liste de scripts potentiellement vulnérables qui
pourront exploités ultérieurement.
War Dialing
Le War Dialing est une technique un peu à part. En effet, cela
consiste à scanner tout un ensemble de numéros de téléphone.
Un logiciel (Toneloc, THC-Scan...) appelle chacun des numéros de
téléphone et détecte s'il s'agit d'une VMB (Voice Mail Box), d'un fax,
d'une personne, d'un type de sonnerie (occupé, pas de réponse...) ou
d'une porteuse c'est à dire un modem (ou plus généralement un Remote
Access) qui répond. L'attaque suivant cette découverte se focalise sur
la découverte d'un login/password permettant d'accéder à la machine
derrière le modem.
L'utilisation des informations
Après avoir récupéré tous ces renseignements sur le système
d'information cible, nous pouvons planifier la suite du test
d'intrusion.
La recherche de vulnérabilités
Cette étape utilise directement les données
précédentes. L'objectif de la phase d'analyse est de trouver les
vulnérabilités au niveau du réseau, des systèmes, et des applications
de la cible. Ces failles se trouvent dans des bases publiques (comme
bugtraq qui est la liste la plus connue) et sur des sites de groupe de
pirates. Cette recherche aboutit à l'établissement d'une liste des
vulnérabilités utilisables contre les machines de la cible.
Dans le cas où de nombreuses machines sont à tester, nous pouvons
utiliser un scanner de vulnérabilités (comme Nessus). Il s'agit d'un
logiciel qui automatise la découverte de vulnérabilités. Celles-ci
sont maintenues au sein d'une base qui peut être mise à jour
on-line. Ce type d'application est très utile mais a ses limites. En
effet, un tel scanner peut remonter de fausses alertes ou, à
l'inverse, ne pas détecter certaines vulnérabilités. Il pourra,
néanmoins, compléter notre liste de failles qui nous sert dans la
dernière étape.
L'exploitation des vulnérabilités
Ces failles sont exploitées en utilisant des outils disponibles
sur Internet ou développés pour l'occasion (en C ou en Perl la plupart
du temps). Cette dernière phase pourra aboutir à la compromission
d'une machine. L'exploitation est très spécifique et dépend évidemment
des vulnérabilités découvertes.
Conclusion
Cet article s'est focalisé sur la recherche d'informations sur la
cible dans l'objectif d'un test d'intrusion externe (via
Internet). Cette phase d'approche est sensiblement la même à chaque
test contrairement à l'attaque en elle-même. En ce qui concerne les
tests d'intrusion internes, la méthodologie reste identique mais le
nombre de vulnérabilités est souvent plus important et les techniques
d'attaque plus nombreuses.
Eric Detoisien -
ede@global-secure.fr
Frédéric Raynal -
pappy@miscmag.com
|
Tous les documents présents sur ce site sont soumis à la
GNU Free Documentation License.
All available documents on these pages are under the
GNU Free Documentation License