Retrouvez cet article dans : Misc 21

De plus en plus, les infrastructures de sécurité intègrent des équipements " transparents " ayant pour objectif d'effectuer une analyse du flux à la volée, sans apparaître de manière explicite sur le réseau. Voyons jusqu'où va cette transparence.

Niveaux d'opérations

Il faut distinguer deux catégories d'équipements transparents : les systèmes travaillant au niveau réseau et ceux travaillant au niveau applicatif.

Systèmes réseau

Au niveau réseau, la transparence peut s'obtenir selon deux techniques. La première consiste à implémenter des fonctions de sécurité sur un élément opérant tel un commutateur, voire un fil, et n'ayant par conséquent aucune interaction au niveau IP. La majeure partie des IP opère selon ce mécanisme. La seconde technique s'appuie sur la translation d'adresse. Dans ces conditions un système n'appartient pas au réseau que présente son adresse IP et tout flux à destination de ce système doit nécessairement passer par un NAT (Network Address Transaltor). Cette seconde catégorie intègre naturellement l'ensemble des firewalls ainsi que certains IP réseau, souvent des firewalls " reconvertis " en fonction des besoins marketing.

Systèmes applicatifs

La transparence au niveau applicatif s'appuie sur les modes opératoires des proxys, à la différence que le passage par le proxy en question est obligatoire et n'impose aucune configuration spécifique sur le poste " utilisateur ". Dans ce schéma, le mécanisme est exactement à l'opposé des systèmes transparents au niveau réseau. En effet, dans le premier cas, les flux vont jusqu'à la cible et sont discrètement analysés. Dans le second, les flux sont à destination du système d'analyse mais sont ensuite transférés vers le système cible, selon un schéma de type " reverse proxy ".
Les principaux systèmes de cette catégorie sont les IP applicatifs (généralement dédiés à un type de flux – le HTTP) auxquels il est cohérent d'ajouter les passerelles anti-virus, apparaissant comme le MX du domaine et transférant les mails au vrai serveur.

Principes de détection

La principale caractéristique des systèmes en ligne est qu’à un moment ou à un autre ils vont opérer en lieu et place du système cible. C’est à ce moment qu’il devient possible d’en détecter la présence. La principale difficulté est donc de forcer le système en ligne à " travailler ". À partir de ce point, la subtilité réside dans l’identification des différences entre le comportement théorique du système cible et celui observé.
En fonction des systèmes, de leur mode opératoire et de leur implémentation, ces différences peuvent être observées à plusieurs niveaux. Il s’agira parfois d’une incohérence des TTL, d’une bannière douteuse ou encore d’IPID ne correspondant pas à ceux attendus sur le système cible.
Il est par conséquent nécessaire de comprendre les différentes catégories d’actions que ces systèmes peuvent effectuer, dans la mesure où ce sont elles qui nous donneront la clef des potentielles anomalies. Bien entendu, plus les opérations sont effectuées à un niveau élevé des couches réseau plus les possibilités de détections sont nombreuses. Ainsi, un système applicatif cumulera généralement les anomalies détectées aux niveaux physique et réseau en plus de celles potentiellement détectables en couche 7.

Pousser le système à la faute

Dans le cas des systèmes applicatifs la majeure partie des opérations sont effectuées par le système en coupure. Il n’est donc pas nécessaire de les " provoquer " et une simple requête, tout à fait légitime, forcera le système à réagir.
Les équipements travaillant au niveau réseau via un mécanisme de translation d’adresse effectuent également des opérations par défaut, à savoir le routage et la plupart du temps l’annonce ARP.
Les autres systèmes ne vont en général pas opérer de manière visible tant qu’ils ne sont pas stimulés par une tentative d’intrusion ou du moins un comportement douteux. Le premier cas est trivial, mais mènera inévitablement (ou presque) à la détection de la source ce qui, cela dit en passant, n’est pas forcément très grave. La notion de comportement douteux est plus subtile. Il s’agit en effet d’activer la mise en place sur le système de mécanismes régis par des seuils. On trouvera ainsi essentiellement les mécanismes de protection contre les scans et les dénis de service par anomalies ou autres SYNFloods.

Critères de reconnaissance réseau

Couche 2

Sur un environnement que nous qualifierons de local, la trame Ethernet contient déjà des informations relativement pertinentes. L’adresse MAC en particulier permet d’identifier très simplement qui répond.

Les incohérences peuvent être de deux ordres :

• la duplication d’une adresse MAC pour deux adresses IP ou plus, caractéristique de NAT ou d’un proxy transparent ;
• le fait que certaines adresses MAC soient caractéristiques. Par exemple, les adresses multicast 01:00:5e:xx:xx:xx sont caractéristiques d’un cluster StoneSoft pour firewall-1.

Couche 3

Les besoins de détection sur un réseau local sont néanmoins limités. Il est donc nécessaire de " monter " dans les couches et de nous intéresser à la couche réseau. Au niveau IP, les champs les plus susceptibles d’être exploités sont essentiellement le TTL et l’IPID.
L’utilisation du TTL permet par exemple de détecter sans coup férir la présence d’un proxy transparent ainsi que de déterminer sa distance par rapport à nous. Ainsi lorsqu’un SYN est envoyé à destination de www.unsitequelconque.com et que le SYN/ACK reçu a un TTL de 62, il est évident qu’un équipement, à deux sauts de notre système, prend en charge l’établissement de la session TCP.
Concernant les systèmes de protection de niveau 3 et 4, qui se trouvent généralement du côté de la " cible ", deux approches peuvent être utilisées à partir du TTL obtenu dans le SYN/ACK (dans le cas d’une connexion " gérée " par l’équipement en question), soit le RST (suite au blocage d’une attaque).
La première technique, qui ne s’applique qu’aux RST, consiste à identifier la distance réelle grâce à un firewalker de type tcptraceroute. Lorsque ce dernier reporte 12 sauts et que le TTL reçu dans le RST est de 54, c’est que nous avons été bloqués à deux sauts de la cible. La seconde solution est tout simplement de " rapprocher " le TTL initial de l’OS probable du système distant. Windows 2000 a un TTL initial de 128. Lorsque le SYN/ACK reçu a un TTL de 52, c’est qu’un système se trouve entre les deux. Notons au passage que certains constructeurs utilisent des TTL aberrants, permettant ainsi une identification immédiate du système soi-disant transparent...
L’usage de l’IPID est plus limité, mais la chance sourit aux audacieux donc il vaut le coup d’être testé. En effet lors de l’établissement d’une session sur un Linux 2.4, il est amusant de remarquer que le premier IPID renvoyé (dans le SYN/ACK) est systématiquement 0. Les paquets suivants reprenant avec un nombre élevé. Ainsi si lors de l’établissement d’une session HTTP sur un serveur IIS, ce dernier renvoi un SYN/ACK avec un IPID nul, c’est qu’il est sûrement derrière un reverse proxy sous Linux.

Couche 4

Deux mécanismes de niveau 4 sont disponibles. Le premier est tout simplement d’effectuer un port sweep sur des adresses aléatoires et sur un port probablement " proxyé ". Lorsqu’il s’avère que tous les systèmes répondent avec un port ouvert, c’est qu’un proxy transparent se trouve dans les parages, à une distance évaluable immédiatement à la lecture du dump du SYN/ACK, comme nous l’avons vu précédemment. Par exemple, un simple scan sur le port 80 d’une classe C (nmap -p 80 194.68.65.0/24) fera l’affaire.
Le second mécanisme est plus subtil et ne s’applique généralement qu’aux systèmes opérant au niveau réseau. Ces derniers, à des fins d’optimisation de performances, n’effectuent pas toujours toutes les vérifications nécessaires au niveau du protocole de transport. Ceci est tout particulièrement vrai en ce qui concerne le checksum TCP. La détection devient alors triviale. Soit le système gère l’établissement des sessions et il répondra à un SYN, soit le checksum TCP est invalide, soit il coupera la connexion (RST ou drop) lors de l’envoi d’une attaque dans un paquet erroné.

Critères de détection applicatifs

Contrairement à ce que l’on peut imaginer, la détection applicative est de loin la plus difficile et la moins scientifique. En effet, les systèmes travaillant au niveau applicatif réagissent en tous points comme l’application cible. Par conséquent, seules quelques subtiles incohérences au niveau des données renvoyées par l’application permettent de détecter un système proxy.
Principalement, il sera habituellement relativement efficace d’identifier qu’un serveur web présentant une bannière " Apache " et ne contenant que des liens vers des pages " .asp " n’est pas celui qu’il laisse paraître. Néanmoins, il est également possible que ce ne soit qu’une simple modification de bannière. Un coup d’œil sur le TTL sera par conséquent nécessaire pour savoir de quoi il retourne.

Mise en Å“uvre

Description de http-ips-detect

Afin de concrétiser les assertions de cet article, nous utilisons un petit programme effectuant automatiquement la plupart des opérations décrites ci-dessus. http-ips-detect [1] est un proof-of-concept tout bête se contentant d’établir des connexions HTTP et de fournir les informations suivantes pour chaque paquet provenant de la destination :

• flags TCP positionnés ;
• valeur du TTL ;
• valeur de l’IPID ;
• taille de la fenêtre TCP.

La requête de base récupère la home page du serveur, sa bannière, le code de retour et compte les extensions des liens présents sur la page. Lorsque le mode exploit est choisi, un second URL est lancé contenant la chaîne cmd.exe, habituellement détectée comme partie d’un exploit IIS Unicode.

Détection locale

Pour ce test local, nous utilisons thcrut [2] afin d’effectuer un scan de niveau 2.

[root@localhost root]# thcrut arp 192.168.202.1-192.168.202.254
thcrut: using source ip 192.168.202.113
thcrut: listening on eth0
192.168.202.1    00:02:a5:46:22:25 Farallon Computing Inc
192.168.202.11   00:02:a5:ea:92:a6 Farallon Computing Inc
192.168.202.25   00:01:02:da:83:d0 INFORMATION TECHNOLOGY LIMITED
192.168.202.205  00:01:02:da:83:d0 INFORMATION TECHNOLOGY LIMITED
192.168.202.204  00:01:02:da:83:d0 INFORMATION TECHNOLOGY LIMITED
192.168.202.230  08:00:37:18:5e:4c Ericsson Business Comm.
192.168.202.100  00:0c:f1:4e:7f:8a FOR-A CO., LTD.
192.168.202.101  00:04:23:95:8c:c8 HP
192.168.202.102  00:0e:35:85:69:59 VIVE Synergies, Inc.
192.168.202.115  00:0e:35:cd:09:3c VIVE Synergies, Inc.
11 packets received by filter, 0 packets dropped by kernel

Dans cet exemple, trois systèmes présentent la même adresse MAC. Il est donc évident que la translation d’adresse a été mise en place. En y réfléchissant bien, il semble également probable que le système effectuant la translation soit le premier de la liste, à savoir 192.168.202.25, dans la mesure où il ne semble pas appartenir à la même partie du plan d’adressage que les deux autres adresses.

Détection de couche 3

Analyse de l’IPID et du TTL

[root@localhost progs]# ./http-ips-detect-v3.pl eth0 10.0.0.101 0 80

+-----------------------------------+
:              Baseline             :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... :  54 :     0 :  5792 : <- Probablement Linux
:  2 : ..A... :  54 : 60559 :  5792 :
:  3 : ..A.P. :  54 : 60560 :  5792 :
:  4 : .FA... :  54 : 60561 :  5792 :
:  5 : ..A... :  54 : 60562 :  5792 :
+----+--------+-----+-------+-------:
+-----------------------------------+
:         Application Level         :
+--------+--------------------------+
: Server :        Microsoft-IIS/5.0 : <- Probablement Pas...
: Code   :                      200 :
+--------+--------------------------+
+ htm    :                        1 :
+ html   :                        1 :
+--------+--------------------------+

Dans ce cas, deux indications nous incitent à nous méfier de cet IIS, innocent. La première est le TTL. Un TTL de 54 ne correspond pas aux réponses fournies par un serveur Windows dont le TTL commence à 128. La seconde indication vient de l’IPID qui commence à 0. Il est fort probable que nous avons ici un reverse proxy tournant sous Linux en frontal de notre cible.

Incohérence des TTL

Lors de l’établissement d’une session

[root@localhost progs]# ./http-ips-detect-v3.pl eth0 10.0.0.102 0 80
+-----------------------------------+
:              Baseline             :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... :  52 : 53594 :  1400 : <- TTL commençant probablement à 64
:  2 : .FA.P. : 116 :  4465 : 17411 : <- TTL commençant probablement à 128
:  3 : ..A... : 116 :  4466 : 17411 :
+----+--------+-----+-------+-------:
+-----------------------------------+
:          Application Level        :
+--------+--------------------------+
: Server :        Microsoft-IIS/5.0 :
: Code   :                      200 :
+--------+--------------------------+
+ htm    :                        1 :
+ html   :                        1 :
+--------+--------------------------+

Ici, c’est la variation du TTL qui trahit la présence du système en ligne. Il est fort probable que ce dernier vérifie dans un premier temps la validité de la session TCP avant d’en " transférer " l’établissement au serveur. Ces mécanismes sont en général mis en place afin de protéger les serveurs contre les SYNFloods.
On remarque également dans ce cas une variation anormale de l’IPID. Ce dernier passe de la valeur 53594 aux valeurs 4465 puis 4466. La variation brutale de l’IPID n’est pas nécessairement étonnante, en particulier sur les systèmes soumis à de fortes charges. Néanmoins, une variation suivie de deux IPID qui se succèdent trahi la présence d’un système tiers.

Lors de la génération d’une commande valide

 [root@localhost progs]# ./http-ips-detect-v3.pl eth0 10.0.0.103 0 80
+-----------------------------------+
:              Baseline             :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... : 243 : 19503 :  8190 : <- TTL commençant probablement à 256
:  2 : ..A... : 243 : 54068 :  8077 :
:  3 : ..A... :  51 : 33741 :  5720 : <- TTL commençant probablement à 64
:  4 : ..A.P. :  51 : 33742 :  5720 :
:  5 : .FA... : 243 : 21052 :  8190 :
+----+--------+-----+-------+-------:
+-----------------------------------+
:          Application Level        :
+--------+--------------------------+
: Server :                  GWS/2.1 :
: Code   :                      200 :
+--------+--------------------------+
+ gif    :                        1 :
+--------+--------------------------+

Ce cas est encore plus intéressant. Le TTL ne varie qu’à l’issue de l’acknowledgement de la requête HTTP. Il est donc probable que la cible est protégée par un système effectuant non seulement le handshake TCP mais vérifiant également la validité de la commande lancée par le client. Ce type de mécanisme est généralement utilisé comme protection contre les attaques de type pending sessions consistant à établir des sessions sans les fermer [3].
Encore une fois, l’IPID peut confirmer notre hypothèse d’un système de protection transparent. La taille de la fenêtre est également un indice intéressant dans la mesure où elle a une valeur stable de 5720 octets lorsque nous sommes directement en contact avec la cible et une valeur de 8190 (une fois 8077) lorsque le système en ligne prend en charge les connexions.

Lors du blocage d’une attaque

Ici http-ips-detect est lancé en mode exploit. Nous obtenons par conséquent les résultats correspondant à la home page et à la page de retour de notre exploit.

 [root@localhost progs]# ./http-ips-detect-v3.pl eth0 10.0.0.104 1 80
+-----------------------------------+
:              Baseline             :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... : 112 :  4449 : 17520 :
:  2 : .FA.P. : 112 :  4450 : 17411 :
:  3 : ..A... : 112 :  4451 : 17411 :
+----+--------+-----+-------+-------:
+-----------------------------------+
:         Application Level         :
+--------+--------------------------+
: Server :        Microsoft-IIS/5.0 :
: Code   :                      200 :
+--------+--------------------------+
+ htm    :                        1 :
+ html   :                        1 :
+--------+--------------------------+

+-----------------------------------+
:              CMD.EXE              :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... : 112 :  4473 : 17520 : <- Probablement 16 sauts
:  2 : ...R.. :  49 :  3241 :     0 : <- Probablement 15 sauts
+----+--------+-----+-------+-------:
+-----------------------------------+
:         Application Level         :
+--------+--------------------------+
: Server :                      200 :
: Code   :                          :
+--------+--------------------------+
+--------+--------------------------+

Notre attaque ayant été bloquée, le TTL nous enseigne non seulement qu’il y a un système en ligne, mais également que ce dernier se situe probablement à un saut de la cible. Par conséquent, il est temps de fourbir son matériel de contournement et de réfléchir à une technique d’insertion [4].

Détection au niveau applicatif

 [root@localhost progs]# ./http-ips-detect-v3.pl eth0 10.0.0.105 0 80
+-----------------------------------+
:              Baseline             :
+-----------------------------------+
:            Network Level          :
+----+--------+-----+-------+-------+
: #  : flags  : ttl : ipid  :  win  :
+----+--------+-----+-------+-------:
:  1 : S.A... :  54 :  7095 : 24616 :
:  2 : ..A... :  54 :  7096 : 24616 :
:  3 : ..A... :  54 :  7097 : 24616 :
:  4 : ..A.P. :  54 :  7098 : 24616 :
:  5 : ..A.P. :  54 :  7099 : 24616 :
:  6 : ..A... :  54 :  7100 : 24616 :
:  7 : ..A... :  54 :  7101 : 24616 :
:  8 : ..A... :  54 :  7102 : 24616 :
:  9 : ..A... :  54 :  7103 : 24616 :
: 10 : ..A... :  54 :  7104 : 24616 :
: 11 : ..A... :  54 :  7105 : 24616 :
: 12 : ..A... :  54 :  7106 : 24616 :
: 13 : ..A... :  54 :  7107 : 24616 :
: 14 : ..A... :  54 :  7108 : 24616 :
: 15 : ..A... :  54 :  7109 : 24616 :
: 16 : ..A... :  54 :  7110 : 24616 :
: 17 : .FA.P. :  54 :  7111 : 24616 :
: 18 : ..A... :  54 :  7112 : 24616 :
+----+--------+-----+-------+-------:
+-----------------------------------+
:         Application Level         :
+--------+--------------------------+
: Server :                   Apache :
: Code   :                      200 :
+--------+--------------------------+
+ asp    :                       12 :
+ css    :                        2 :
+ gif    :                       47 :
+ htm    :                        4 :
+ pdf    :                        1 :
+--------+--------------------------+

Enfin, le cas le moins probant, trahissant cependant la possibilité d’un reverse proxy transparent tournant sous Apache et protégeant un serveur IIS, plein de pages ASP !

Conclusion

La transparence absolue est très difficile à obtenir dans la mesure où elle nécessite d’un système qu’il imite exactement le système qu’il protège. Ceci est vrai au niveau des caractéristiques réseau, système et applicatives mais également en termes de connaissance de la topologie et du contexte global de déploiement.
Ainsi le TTL doit être calculé en fonction de la nature (TTL initial) et de la position de la cible relative de la cible, la bannière devrait correspondre au contenu, les IPID rester cohérents, etc. Tout ceci est techniquement simple à prendre en compte et ne demande qu’un paramétrage certes relativement pointu mais accessible dès lors que l’architecture à protéger est maîtrisée.

Outils et Références

• [1] http-ips-detect – http://www.iv2-technologies.com/~rbidou/http-ips-detect.tar.gz
  
• [2] thcrut – http://thc.org/thc-rut/
  
• [3] Dénis de Service réseau – MISC 18. 
• [4] Principe et contournement des IDS – MISC 3.

Retrouvez cet article dans : Misc 21