Association Générale des Utilisateurs de logiciels libres en Côte-d'Or

logo_coagul

De la reconnaissance de système d’exploitation à distance au camouflage

Rubrique : Sécurité
Le : lundi 14 février 2005
Par : GnunuX  
Visites : 5861

Les différents systèmes d’exploitation ont des caractèristiques particulières. La reconnaissance d’un système d’exploitation passe par la récolte d’information qui va nous permettre de déterminer le système d’exploitation distant.

Dans la suite nous utiliseront deux machines (il est obligatoire d’avoir deux machines) :

la première machine :
- ip : 192.168.12.1
- mac : 00:10:AA:1B:CB:AA

la deuxième machine :
- ip : 192.168.12.2
- mac : 00:06:25:AA:57:3A
- port : 22
- noyau : 2.4.24

Il n’y a aucun firewall sur aucune des machines.

Les services

Pour lister les services de la machine distante nous allons utiliser nmap [1] :

# nmap -sV 192.168.12.2

Nous auront par exemple :

80/tcp open http Apache httpd 2.0.50 ((YDL))

Nous savons alors que c’est une yellow dog ;)

Certains services sont plus courant sur un système ou un autre (par exemple netbios est courant sous windows et moins sous unix).

Pour se protéger, il faut limiter le nombre de service sur les machines. De plus, il est possible bien souvent de retirer les bannières des services.

Les implémentations réseaux

Il y a des différences dans les implémentations réseaux. Nous allons voir trois outils qui utilise cette technique :

- nmap :

Nmap est une boite à outil du scan. Il se sert principalement des paquets TCP (souvent mal formaté) pour déterminer une empreinte d’un système.

# nmap -O 192.168.12.2 -p 22 -sS
[...]
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 12.063 days (since Wed Jan 26 22:15:44 2005)

- Xprobe2 [2]

Xprobe2 travaille surtout au niveau ICMP

# xprobe2 -p tcp:22:open 192.168.12.2
[...]
[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.3" (Guess probability: 100%)[+] Other guesses:
[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.2" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.7" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.6" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.5" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.4" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.1" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.6.0" (Guess probability: 100%)[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.4.28" (Guess probability: 100%)
[+] Host 192.168.12.2 Running OS: "Linux Kernel 2.4.27" (Guess probability: 100%)

- p0f [3]

Contrairement à nmap et Xprobe2 p0f ne se connecte à un serveur distant. Il attent qu’on se connecte à lui.

# p0f

Sur l’autre machine :

# ssh 192.168.12.2

Résultat :

192.168.0.2:1456 - Linux 2.4/2.6 <= 2.6.7 (up: 333 hrs)
 -> 192.168.0.25:80 (distance 0, link: ethernet/modem)

Exemple de particularité lié au système d’exploitation : le RTO

Nous allons étudier le fonctionnement des sessions TCP. Pour établir une session, il faut procéder à trois étapes.

La machine voulant établir une connexion envoi un paquet SYN avec un numéro de séquence. La machine distante répond par un paquet avec l’option ACK et le numéro de séquence + 1. Dans le même paquet, la machine distance demande si la machine est prête à ouvrir la session avec avec l’option SYN et un numéro de séquence. Enfin la première machine répond avec un paquet ACK avec les deux numéros de séquence + 1.

ouverture de session TCP

Suite à ce processus, comportant trois échanges, les deux machines sont synchronisées et la communication peut commencer.

Le but du RTO (retransmission timeout) est d’envoyer un paquet SYN et de ne jamais renvoyer la réponse ACK. Suivant les systèmes d’exploitation, le comportement est différent.

Voyons en pratique ce que cela donne : Nous envoyons un paquet (-c 1) de type SYN (-S) avec l’adresse source mystifié de 192.168.12.3 (machine qui n’existe pas) sur le port ouvert 22 :

# hping2 -S -a 192.168.12.3 192.168.12.2 -p 22 -I eth0 -c 1

Linux envoi une requête ARP pour connaître l’adresse MAC de la machine 192.168.12.3. Il nous faut mystifier une réponse ARP (voir Jouons avec ARP) :

./send_arp 192.168.12.3 00:09:5B:B2:2D:78 192.168.12.2 00:10:A7:1B:CB:AD

Sous linux nous remarquons qu’il envoi 6 paquets avec un intervalle de plus en plus loin. Sous freeBSD 4.8 il n’y aurait eu que 4 paquets à intervalle régulier. N’ayant pas de RFC décrivant explicitant la marche à suivre, chaque système à une implémentation de façon différente.

Contrer les détections

Il n’y a pas de technique sûr pour contrer ce genre d’attaque. Nous pouvons jouer sur les options réseaux pour tromper les tests.

Dans un premier test, nous allons limiter les réponses aux paquets mal-formatés.

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --tcp-flags ALL SYN -j ACCEPT

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Avec nmap (en ajoutant l’option -vv), nous voyons qu’il se trompe. En effet, seuls deux des sept tests fonctionnent.

Device type: general purpose|media device
Running: Linux 2.4.X|2.6.X, Pace embedded
OS details: Linux 2.4.21 (Suse, X86), Linux 2.4.6 - 2.4.21, Linux 2.6.8 (Debian), Pace digital cable TV receiver
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=328779%IPID=Z%TS=100HZ)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=N)
T4(Resp=N)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)

xprobe2 et p0f sont moins précis.

Nous allons changer quelques options de la couche TCP pour essayer de tromper les outils :

D’abord, nous allons augmenter la valeur de ttl (ttl représente le TimeToLive ou la durée de vie du paquet). De 64, nous passons à 128 :

echo 128 > /proc/sys/net/ipv4/ip_default_ttl

Enfin nous allons désactiver deux options TCP :

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

p0f et xprobe2 seront ainsi trompé. Attention, changer les options de la couche TCP peut avoir des conséquence sur les performances réseaux.

[1] http://www.insecure.org/nmap/

[2] http://xprobe.sourceforge.net/

[3] http://lcamtuf.coredump.cx/p0f.shtml

Version imprimable de l'article

Forum


Site réalisé sous Spip. Merci à NFrance pour son hébergement gracieusement offert. Tous les articles de ce site sont sous licence Creative Commons by-nc-sa (CC).