Les leaktests en tant qu’outil d’évaluation de l’efficacité du pare-feu

Dans les conditions actuelles, le pare-feu est devenu un élément incontournable des systèmes de protection sophistiqués. Même les systèmes d’exploitation les plus récents tels que Windows Vista ne peuvent bloquer à eux seuls tous les types de leak tests (depuis Windows XP SP2, le système d’exploitation Windows propose un pare-feu dont les fonctions ont été considérablement élargies avec l’arrivée de Windows Vista).

Un pare-feu est un élément complémentaire de sécurité qui fait de plus en plus souvent parler de lui au fur et à mesure que le rythme de création de nouveaux programmes malveillants s’accélère. Le pare-feu permet de bloquer le trafic de réseau indésirable, aussi bien depuis le réseau que vers celui-ci. Les leaktests du pare-feu dont il sera question dans cet article permettent de vérifier la fiabilité du pare-feu du point de vue du contrôle du trafic sortant et de l’efficacité de la protection contre les fuites d’informations.

Qu’est-ce qu’un pare-feu ?

Une des tâches principales que doivent remplir les systèmes complexes de sécurité est d’offrir à l’utilisateur les moyens de contrôler le trafic de réseau autrement dit les données transmises et reçues via le réseau par les applications qui tournent sur l’ordinateur de l’utilisateur. Le composant qui remplit cette fonction est le pare-feu (firewall en anglais). Le pare-feu peut être logiciel ou matériel (http://fr.wikipedia.org/wiki/Pare-feu_personnel). Cet article abordera uniquement les pare-feu logiciels.

Il existe un nombre élevé de logiciels pare-feu commercialisés ou distribués gratuitement. Le pare-feu installé sur une passerelle d’accès (par exemple, le serveur qui transfère les données entre les différents réseaux) est un pare-feu conventionnel. Le pare-feu installé sur l’ordinateur de l’utilisateur est un pare-feu personnel car il protège uniquement l’ordinateur de l’utilisateur. Ces derniers temps, les pare-feu personnels sont souvent intégrés aux systèmes de protection des ordinateurs. Ainsi, Kaspersky Internet Security 7.0 possède un pare-feu.


Ill. 1. Composant « Pare-feu » dans KIS 7.0

Afin d’exécuter sa fonction principale, à savoir le contrôle de l’activité du réseau, le pare-feu utilise des listes de règles qui autorisent ou interdisent l’activité de réseau de diverses applications. Chaque règle peut contenir différents paramètres tels que le sens de transmission des données, le protocole de transfert des données (IP, TCP, UPD, ICMP, etc.) ainsi que les adresses IP, le port local et le port distant des ordinateurs impliqués dans l’échange de données.

La règle de contrôle de l’activité de réseau peut s’appliquer à toutes les applications du système, dans ce cas on parlera de règles pour paquets.


Ill. 2. Exemples de règles pour Microsoft Outlook
dans KIS 7.0

Les pare-feu modernes peuvent travailler selon deux modes : avec ou sans intervention de l’utilisateur. Lorsque le pare-feu fonctionne sans intervention de l’utilisateur, il peut :

  1. Autoriser toute activité qui n’est pas interdite par les règles ;
  2. Interdire toute activité qui n’est pas autorisée par les règles ;
  3. Autoriser toutes les activités réseau.

Le mode principal de fonctionnement du pare-feu est le mode impliquant l’intervention de l’utilisateur, à savoir le mode d’apprentissage. Dans ce mode, lorsque le pare-feu détecte une activité qui ne tombe sous le coup d’aucune des règles définies, il présente à l’utilisateur une boîte de dialogue qui permet à ce dernier d’autoriser ou d’interdire l’action de manière ponctuelle ou de rédiger une règle pour ce type d’activité de réseau.


Ill. 3. Exemple de fenêtre d’apprentissage du
pare-feu dans KIS 7.0

Dans la mesure où l’utilisateur moyen peut disposer de plusieurs dizaines d’applications différentes ayant chacune leur activité de réseau, la rédaction manuelle de la liste des règles décrivant l’activité de réseau d’une application particulière demande beaucoup de temps. C’est la raison pour laquelle tous les éditeurs de pare-feu propose une base de règles préconfigurées pour les applications de réseau les plus connues telles que Internet Explorer, Microsoft Outlook, Generic Host Process for Win32 Services (svhost.exe), Microsoft Application Error Reporting (dwwin.exe) et beaucoup d’autres.


Ill. 4. Liste des règles préconfigurées dans le pare-feu
de KIS 7.0 pour les applications

Du point de vue du contrôle des données sortantes et de la protection contre les fuites d’informations depuis l’ordinateur, le principe de fonctionnement d’un pare-feu peut être illustré de la manière suivante :


Ill. 5. Concept de fonctionnement du pare-feu

Le pare-feu constitue un « mur » entre les applications sur l’ordinateur de l’utilisateur et les autres ordinateurs connectés au réseau local et à Internet. Pour les applications connues ou de confiance (marquées en vert sur l’illustration 5), il existe des règles d’autorisation (point de passage dans le mur) qui leur permettent de transmettre les données via le pare-feu vers le monde extérieur. L’activité de réseau des autres applications sera interceptée (elle se « heurte au mur ») et ces applications ne peuvent transmettre leurs données à l’extérieur (ni recevoir des données depuis l’extérieur). L’utilisateur peut toujours créer à n’importe quel moment de nouvelles règles d’autorisation (percer de nouveaux « trous » dans le « mur ») après quoi les applications pourront interagir avec les réseaux extérieurs.

Il convient de noter que certains pare-feu possèdent un composant de protection contre les intrusions (attaques de réseau). Ce composant analyse le trafic entrant et sortant afin d’identifier la présence éventuelle de paquets de réseau correspondant à des modèles d’attaques de réseau connues repris dans une base. Nous consacrerons un article séparé à l’étude détaillée de ce composant.

En quoi le pare-feu contribue-t-il à la sécurité ?

Le pare-feu représente une « couche » supplémentaire de protection qui peut contribuer à l’interruption du fonctionnement d’un programme malveillant lorsque ce dernier n’a pas été détecté par l’antivirus d’un système de protection complexe. Une telle situation peut se présenter lorsque les bases antivirus ne contiennent pas encore la définition du programme malveillant (l’approche traditionnelle selon la signature est inopérante) ou si le programme malveillant ne présente pas un comportement carrément dangereux ou suspect (le composant d’analyse du comportement échoue).

Un pare-feu est-il en mesure d’offrir une protection contre ces types de programmes malveillants ? Oui, pratiquement contre la majorité des programmes malveillants existants à l’heure actuelle. Cette affirmation peut paraître quelque peu audacieuse mais c’est bel et bien la vérité : les fonctions de la majorité des programmes malveillants sont liées à l’activité de réseau et par conséquent, ils peuvent être bloqués grâce à un pare-feu.

Les vers de réseau diffusent leurs copies via les réseaux locaux et/ou mondiaux.

Les chevaux de Troie, représentant à l’heure actuelle 91,4% de l’ensemble des programmes malveillants, échangent également des données via le réseau dans le cadre de leur « travail ». Les chevaux de Troie reprennent :

  • Les portes dérobées qui sont des utilitaires permettant l’administration à distance des ordinateurs du réseau. L’administration via des portes dérobées s’effectue à distance et le pare-feu peut bloquer toutes les fonctions des programmes malveillants de ce type.
  • Les Trojan-PSW sont des programmes qui « volent » diverses informations qui se trouvent sur l’ordinateur infecté. Une fois que les données ont été volées, le cheval de Troie doit les transmettre d’une manière ou d’une autre à son auteur et c’est à ce moment que le pare-feu peut intercepter la tentative de transfert et protéger les données de l’utilisateur.
  • Les Trojan-Downloader sont des programmes développés pour télécharger et installer sur l’ordinateur de la victime de nouvelles versions des programmes malveillants, installer des chevaux de Troie ou des systèmes de publicité. Tout le travail des programmes malveillants de ce type repose sur l’échange de données via le réseau et par conséquent, ils peuvent être aisément bloqués à l’aide d’un pare-feu.
  • Les Trojan-Proxy sont des programmes qui réalisent des accès anonymes à diverses ressources Internet à l’insu de l’utilisateur. Ils servent généralement à diffuser du courrier indésirable. A l’instar de la catégorie précédente de chevaux de Troie, les programmes de la catégorie Trojan-Proxy peuvent être aisément bloqués sur la base de l’activité de réseau qu’ils lancent dans leur fonctionnement.
  • Les Trojan-Spy sont des programmes qui espionnent électroniquement l’utilisateur de l’ordinateur infecté. Les informations saisies à l’aide du clavier, les captures d’écran, la liste des applications actives et les actions réalisées par l’utilisateur avec celles-ci sont enregistrées dans un fichier sur le disque qui est envoyé à intervalles définis à l’individu mal intentionné. C’est à ce moment que le pare-feu peut bloquer la tentative d’envoi des données par un programme inconnu. Ainsi, les données volées ne peuvent pas tomber entre les mains de l’auteur du programme malveillant.

Il convient de remarquer que les pare-feu ne peuvent être utilisés pour lutter contre les virus informatiques classiques car, à la différence des vers, les virus n’utilisent pas les services de réseau pour s’infiltrer dans d’autres ordinateurs et à la différence des chevaux de Troie, les virus n’ont pas besoin d’envoyer des données quelconque ou de recevoir des commandes.

Le pare-feu est un moyen de protection difficilement contournable car pour déjouer un logiciel antivirus ou un inhibiteur de comportement, l’auteur du programme malveillant peut réaliser des tests « à domicile » sur son nouveau programme malveillant et introduire les modifications requises jusqu’à ce que les composants cités ne détectent plus le code malveillant. Il est plus difficile de contourner un pare-feu en utilisant la même méthode car si le programme a besoin d’une activité réseau quelconque, il est très difficile de le dissimuler aux yeux du pare-feu. Le seul moyen envisageable est de recourir aux leaktests.

Qu’est-ce que la perméabilité et les leaktests

La perméabilité (leak) est une technologie de contournement des mécanismes de contrôle de l’activité de réseau du pare-feu qui permet aux applications privées de règles d’autorisation dans la liste des règles du pare-feu d’envoyer des données depuis l’intérieur. Le pare-feu ne bloque pas l’envoi et en mode d’apprentissage, il ne signale pas cette activité de réseau à l’utilisateur.

Un pare-feu bien conçu ne peut accepter aucune fuite et il doit identifier toutes les tentatives d’activité de réseau entrante et sortante. C’est la raison pour laquelle deux critères interviennent dans la définition de la qualité d’un pare-feu : la qualité du contrôle des données entrantes (protection contre l’intrusion dans l’ordinateur) et la qualité du contrôle des données sortantes (protection contre la fuite d’informations depuis l’ordinateur).

Pour tester la qualité de la protection offerte par le pare-feu contre les intrusions dans l’ordinateur, il existe divers balayeurs de ports ouverts (par exemple, ShieldsUP!, Quick test, etc.).

Pour analyser la qualité de la protection contre les fuites offerte par le pare-feu, il est possible de recourir aux leaktests (petits programmes qui réalisent une ou plusieurs fuites). Ces programmes sont écrits en général par des chercheurs et des experts de la sécurité informatique.

Il est évident que la seule manière d’organiser des fuites est d’utiliser les « orifices » (règles d’autorisation) qui existent déjà pour les applications connues. Toutefois, il faut pour cela « convaincre le pare-feu » que cette activité de réseau a bien été entamée par une application de confiance. Il existe pour cela diverses méthodes. Avant de les étudier, il convient de rappeler les principes élémentaires de l’exécution des applications dans les systèmes d’exploitation modernes.


Ill. 6. Démonstration d’une fuite

Principes d’exécution des applications dans les systèmes d’exploitation modernes

Le processeur central d’un ordinateur personnel est capable d’exécuter un ensemble d’instructions placées dans la mémoire vive de l’ordinateur. Les ensembles d’instructions sont regroupés en unités d’exécution qui appartiennent à des processus définis situés à ce moment dans la mémoire vive.

Les fichiers exécutables contiennent les ensembles d’instructions du processeur et c’est leur exécution qui entraîne l’apparition d’un nouveau processus dans le système. De plus, le processus peut être engendré par un autre processus. Le système d’exploitation possède une arborescence de processus dans la mémoire vive.

Il convient de remarquer que l’espace d’adressage de la majorité des processus du système contient non seulement le code du fichier exécutable de l’application mais également le code d’une multitude de bibliothèques de liens dynamiques (dll, dynamic link library). Ces bibliothèques servent à écrire certaines fonctions générales indispensables à quelques applications et les développeurs des applications n’ont pas besoin de reproduire le même code de programmation dans divers fichiers exécutables. La même bibliothèque dynamique peut être chargée dans les espaces d’adressage de divers processus.


Ill. 7. Principe d’exécution des applications

Classification des leaktests

Idées élémentaires de l’organisation des leaktests

Examinons les technologies que les programmes malveillants peuvent exploiter pour « tromper » un pare-feu. En guise de point de départ, examinons la situation illustrée au schéma 8 : la mémoire vive contient les processus d’applications de confiance connues de l’application et le processus d’une application inconnue (malveillante).


Ill. 8. Situation de départ pour l’organisation de fuites

La tentative menée par l’application inconnue pour réaliser une activité de réseau en son nom sera bloquée ou entraînera l’affichage d’une fenêtre demandant de confirmer l’action.

Il existe 3 idées fondamentales pour contourner la protection offerte par le pare-feu :

  1. Tromper le pare-feu, le « convaincre » que l’activité de réseau émane d’une des applications de confiance en remplaçant le fichier exécutable d’une des applications de confiance sur le disque ou en remplaçant les données d’un processus inconnu dans la mémoire par celles d’un processus connu.
  2. Exécuter le code au nom d’une application de confiance en introduisant un fichier dll ou simplement, une petite partie du code de l’application inconnue dans l’espace d’adressage d’un processus de confiance. Le pare-feu ne peut pas faire la différence entre l’activité de réseau de ces éléments intégrés et l’activité de réseau traditionnelle d’une application de confiance.
  3. Utiliser les interfaces documentées proposées par les applications de confiance. En cas d’utilisation de telles interfaces, l’activité de réseau proviendra des applications de confiance, toutefois elle sera contrôlée par l’application qui n’est pas de confiance, ce qui lui permet d’envoyer les données via ces interfaces de l’intérieur sans avertissement du pare-feu.

Pour appliquer ces trois idées, il existe 6 technologies de leaktests :

№№ Idée 1
(tromper)
Idée 2
(exécution du code au nom de l’application de confiance)
Idée 3
(utilisation d’interfaces documentées)
1 Substitution    
2   Launching  
3   DLL injection  
4   Code injection  
5     Browser services
6     System services

Examinons plus en détail ces différentes technologies et leurs variantes.

Technologies des leaktests

Substitution

Substitution du fichier exécutable d’une des applications de confiance sur le disque ou substitution dans la mémoire des données du processus inconnu par les données d’un processus de confiance. Le but de la méthode de substitution est de « convaincre » le pare-feu que l’activité de réseau émane d’une application de confiance.

Il existe trois méthodes de substitution :

  • Substitution du fichier exécutable d’un des processus de confiance sur le disque (méthode adoptée par le test Runner, cf. « Leaktests) » ;
  • Remplacement du nom du fichier de l’application inconnue par le nom du fichier de l’application de confiance (Leaktest) ;
  • Remplacement dans la mémoire d’un modèle déjà chargé de processus de données du fichier inconnu par les données d’un processus de confiance (Coat).

Le schéma ci-après illustre la première variante de substitution :


Ill. 9. Méthode de substitution d’un fichier d’un processus
de confiance sur le disque

Launching

Lancement d’une application de confiance avec les paramètres de la ligne de commande. L’idée de cette méthode repose sur le fait que la majorité des navigateurs Internet acceptent des adresses de pages Internet qu’il faut ouvrir sous la forme de paramètre de la ligne de commande. Si du côté du serveur Web, un script est placé sur la page Web (par exemple, cgi), alors il est possible de transférer via la ligne d’adresse des paramètres qui seront transmis à l’entrée du script. Ces paramètres peuvent reprendre des informations confidentielles volées, par exemple, par un logiciel espion. Dans ce contexte, toute l’activité de réseau est réalisée par le navigateur dans son état normal, ce qui est toujours autorisé par les règles du pare-feu.

Afin que l’utilisateur ne remarque pas l’ouverture de la fenêtre du navigateur, le navigateur est lancé en mode « silencieux » (Ghost, TooLeaky, Wallbreaker [1]).

De plus, le code malveillant peut lancer le navigateur indirectement à l’aide d’autres applications, par exemple :

  • Lancement du navigateur via le processus Windows Explorer.exe (Wallbreaker [2]) ;
  • Lancement du navigateur via le processus Windows Explorer.exe qui à son tour est lancé via l’interprète de commande cmd.exe (Wallbreaker [3]) ;
  • Lancement du navigateur à l’aide du mécanisme de lancement programmé des tâches de Windows (Wallbreaker[4]) ; dans ce cas, la séquence des requêtes est AT.exe — Svchost.exe — Cmd.exe — Explorer.exe — IExplore.exe.

Le schéma ci-après illustre cette méthode de leaktests :


Ill. 10. Méthode basée sur le lancement d’une application
de confiance avec les paramètres de la ligne de commande

DLL injection

Insertion d’une bibliothèque dynamique dans l’espace d’adressage d’un des processus de confiance. Cette méthode repose sur le chargement dans l’espace d’adressage d’un processus de confiance de la bibliothèque dynamique du programme malveillant. Il existe plusieurs moyens pour arriver à ce résultat. Vous trouverez ci-après les principaux :

  • Installation d’un piège global dont le code est situé dans la bibliothèque dynamique (CPILSuite [2,3], FireHole, pcAudit, pcAudit2);
  • nscription dans la base de registres système dans la liste des dll chargées automatiquement par le système dans chaque nouveau processus, – argument AppInit_DLLs (Jumper).

Ces deux méthodes sont légales et documentées.

Le schéma ci-après illustre cette méthode de leaktest :


Ill. 11. Méthode d’insertion d’une bibliothèque dynamique dans
un processus de confiance

Ñode injection

Insertion de code dans l’espace d’adressage d’un des processus de confiance. Cette méthode repose sur l’insertion dans l’espace d’adressage du processus de confiance d’un code exécutable qui pourra par la suite réaliser n’importe quelle activité de réseau. Le pare-feu la considérera comme une activité de réseau émanant d’une application de confiance. A la différence de la méthode précédente, cette opération est assez suspecte, même s’il existe des moyens documentés pour introduire du code dans un autre processus. Une telle insertion de code est parfois pratiquée par des programmes habituels (par exemple, des débogueurs) mais en général, elle est utilisée par des programmes malveillants.

Les moyens pour insérer du code dans un autre processus sont assez nombreux. Vous trouverez ci-après quelques exemples :

  • Chargement d’un processus de confiance dans la mémoire et modification de la mémoire du processus (AWFT [1], CPIL, DNStest), dans ce cas, il peut y avoir une tentative préalable de se protéger contre la détection de cette opération par le pare-feu en enlevant les crochets (CPILSuite[1]) ;
  • Identification d’un processus de confiance chargé dans la mémoire et insertion du code dans celui-ci (Thermite) ;
  • Chargement d’un processus de confiance dans la mémoire et création dans celui-ci d’un flux distant (AWFT [2,3]) ;
  • Chargement d’un processus de confiance dans la mémoire, création dans ce dernier d’un flux distant, chargement depuis ce flux d’un autre processus de confiance et changement de sa mémoire avant l’exécution (AWFT [4, 5, 6]) ;
  • Utilisation de la fonction SetThreadContext pour prendre le contrôle du flux dans le processus de confiance (CopyCat).

Ce sont les processus du navigateur qui sont le plus souvent attaqués (Internet Explorer et autres – tests AWFT [1,2,4], CopyCat, Thermite), les thèmes du système d’exploitation (explorer.exe – tests AWFT [3,4], CPIL, CPILSuite [1]) et le processus svchost.exe, processus principale des services Windows, chargés depuis les bibliothèques dynamiques (test DNStest).

Le schéma ci-après illustre cette méthode de leaktest :


Ill. 12. Méthode d’insertion de code malveillant dans
le processus de confiance

Browser services

Utilisation d’interfaces logicielles pour l’administration du navigateur Internet. La méthode repose sur l’utilisation de divers mécanismes intégrés au système d’exploitation Windows pour l’interaction inter-processeurs entre divers composants/applications. Ces mécanismes comprennent :

  • Envoi des messages Windows à la fenêtre du navigateur Internet ; ainsi la valeur dans la barre d’adresse du navigateur change et lorsque vous appuyez sur le bouton Go, vous lancez l’ouverture de la nouvelle adresse (Breakout) ;
  • Utilisation de l’interface DDE du navigateur, mécanismes d’échange dynamique de données DDE (Dynamic Data Exchange). La bibliothèque DDE a été développée pour élargir les possibilités du système de communication Windows et permet à deux applications d’échanger des données de manière dynamique durant l’exécution (la prise en charge de DDE dans diverses versions du navigateur Internet Explorer est décrite dans l’article http://support.microsoft.com/kb/q160957) (Surfer, Zabypass, WB [1,3,4], CPILSuite [3]) ;
  • Utilisation du navigateur en tant que serveur d’automatisation (mécanisme OLE automation qui repose sur le modèle COM. L’automatisation OLE est une extension de la technologie DDE. Tout navigateur moderne propose une interface COM (http://ru.wikipedia.org/wiki/COM) qui peut être utilisée dans d’autres programmes en guise de serveur d’automatisation. Il existe deux composants COM Microsoft Internet Explorer dans les applications externes :
    • WebBrowser Control, dans le fichier shdocvw.dll (OSfwbypass) ;
    • Interface MSHTML, dans le fichier mshtml.dll (PCFlank).

Le schéma ci-après illustre cette méthode de leaktest:


Ill. 13. Méthode d’utilisation des interfaces logicielles
pour l’administration du navigateur

System services

Utilisation des interfaces logicielles offertes par les services système. Cette méthode ressemble à la méthode précédente. La seule différence réside dans le fait qu’elle repose sur l’utilisation des interfaces logicielles proposées par les composants du système d’exploitation et non pas par le navigateur Internet. Les systèmes d’exploitation Windows XP et Windows Vista proposent au moins trois interfaces de ce type :

  • Le service BITS (Background Intelligent Transfert Service), service intelligent de chargement des fichiers à l’aide des services Windows Update et Windows Server Update Services, garantit la possibilité de télécharger les correctifs et les mises à jour en arrière plan sans surcharger les canaux de communication et en reprenant automatiquement le téléchargement en cas de déconnexion (BITSTester) ;
  • Les fonctions Windows DNS API peuvent être utilisées pour organiser une requête DNS récursive vers le serveur de noms sur Internet. Le paquet DNS peut contenir des données complémentaires, parmi lesquelles les données confidentielles de l’utilisateur. L’individu mal intentionné qui contrôle un des serveurs de nom chargés du traitement de ces requêtes DNS peut obtenir ces informations après avoir traité un de ces paquets formés spécialement (DNStester) ;
  • Interface d’administration des éléments du bureau et des thèmes Windows (LactiveDesktop) permet, après avoir activé Windows Active Desktop, de définir une page HTML Windows en guise de thème du Bureau. La page HTML peut contenir des éléments qui font référence à des ressources externes, ce qui entraîne le chargement de ces ressources lors de l’activation de nouveaux thèmes du Bureau (Breakout2).

Différences entre les classifications existantes des leaktests

Il convient de signaler que la classification présentée ci-dessus diffère quelque peu de la classification des technologies de leaktests à la sortie utilisée sur les sites spécialisés dans l’analyse de la perméabilité.
Le premier site que nous avons découvert et qui propose une étude systématique des leaktests est le site http://www.firewallleaktester.com. La classification des tests figure à la page http://www.firewallleaktester.com/categories.htm.

Un deuxième site, http://www.matousec.com, est apparu en 2006. Un des projets les plus importants de ce site est intitulé « Etude des pare-feu personnels Windows » (http://www.matousec.com/projects/windows-personal-firewall-analysis/introduction-firewall-leak-testing.php). Le classement des leaktests dans cette enquête est proche de celui utilisé sur le site http://www.firewallleaktester.com, mais il existe plusieurs différences.

Nous allons présenter ces différences dans des classifications. Notre classification ignore les méthodes suivantes :

№№ Méthodes sur
www.firewallleaktester.com
Méthode sur
www.matousec.com
1 Hidden rules (règles cachées) Default Rules règles par défaut)
2 Direct network interface use (utilisation directe de l’interface réseau) Own Protocol Driver (propre pilote de protocole)
3 Timing attack (attaque programmée)  
4 Recursive requests (requêtes récursives)
5 Registry injection (intrusion dans la base de registres)  
6 Sélection de méthodes Windows Messaging + OLE Windows Messages et OLE Automation, DDE
7   Unhooking (désactivation des interceptions)

Ci-après, vous trouverez les raisons pour lesquelles ces méthodes ne figurent pas dans notre classification :

  1. La méthode des « règles cachées » n’est pas un leaktest (cf. définition ci-dessus) car elle n’exploite aucune des technologies de contournement des mécanismes de contrôle de l’activité de réseau par le pare-feu. Elle consiste à analyser un ensemble de règles de paquets (applicables à toutes les applications du système) utilisées par le pare-feu avec les paramètres par défaut. Si un des ports de réseau est ouvert pour toutes les applications, il peut être utilisé par une application malveillante pour envoyer les données de l’intérieur.
  2. La méthode « Utilisation directe de l’interface de réseau » repose sur le contournement des mécanismes de filtrage du trafic de réseau au niveau « faible ». Elle consiste à écrire une pile alternative de pilotes de réseau qui, en parallèle avec les piles systèmes (TPC/IP, etc.) traite les paquets qui proviennent de l’adaptateur de réseau. Cette méthode ne figure pas dans notre classification car à l’heure actuelle, il n’existe aucune version (leaktests) fonctionnant sous Windows XP/Vista. De plus, l’apparition de nouveaux leaktests ou de programmes malveillants exploitant cette méthode est peu probable car elle est plus difficile à mettre en œuvre que n’importe quelle autre méthode d’organisation de fuites. Il faut toutefois noter trois leaktests à la sortie qui fonctionnent sous Windows 9x et qui utilisent cette méthode :
    1. MbTest (auteur – “mbcx8nlp”, 2003), utilise la bibliothèque Winpcap.
    2. Outbound (auteur – HackBusters, 2001).
    3. YALTA [2] (auteur – Soft4ever, 2001).
  3. La méthode de l’ « attaque programmée » ne figure pas dans une catégorie distincte de notre classification car à l’heure actuelle, la technologie qu’elle utilise (redémarrage de son propre processus pour modifier l’identifiant du processus, PID) ne permet de contourner aucun pare-feu.
  4. La méthode des « requêtes récursives » fait partie, dans notre classification, des méthodes du groupe System services.
  5. La méthode « Intrusion dans la base de registres » se retrouve dans notre classification parmi les différentes variantes de la méthode DLL injection car l’objectif de cette méthode n’est pas de s’introduire dans la base de registres, mais bien à introduire une bibliothèque dynamique dans les processus de confiance. En effet, un des moyens utilisés pour ce faire est l’utilisation d’une clé spéciale dans la base de registre système.
  6. Les méthodes regroupées sous le nom « Windows Messaging + OLE » se retrouvent dans notre classification dans le groupe Browser services et System services. Cette distinction nous semble plus logique car elle exprime non pas les méthodes techniques (envoi de messages, etc.) mais bien l’essence de la technologie de leaktest à un niveau supérieur : utilisation des interfaces logicielles d’administration du navigateur ou des services de réseau du système d’exploitation.
  7. La méthode « Désactivation des interceptions ». L’idée de cette méthode repose sur l’élément suivant : les pare-feu, dans le cadre de la lutte contre certains leaktests, utilisent l’interception des fonctions système (ce qu’on appelle les « crochets »). Lorsque ces interceptions sont suspendues, le pare-feu ne peut plus lutter contre les leaktests. La description montre que la méthode en tant que telle n’est pas un leaktest et c’est la raison pour laquelle elle ne figure pas dans la classification principale des leaktests. Toutefois, son utilisation avec n’importe quelle autre méthode réelle permet de tester la protection offerte par un pare-feu contre ce leaktest dans les conditions les plus difficiles, en simulant le cas où un code malveillant lutte activement contre un pare-feu.

Utilisation des leaktests dans les programmes malveillants

Il y a quelques années, le pare-feu était très rarement utilisé en tant que moyen de protection pour les ordinateurs personnels. Par conséquent, seuls quelques exemplaires de programmes malveillants utilisaient des leaktests pour contourner le pare-feu. Toutefois, ces derniers temps, les auteurs de programmes malveillants utilisent des méthodes d’automatisation pour obtenir rapidement de nouvelles copies de leurs programmes et le flux de programmes malveillants ne fait que s’accélérer. Dans ce contexte, le rôle des moyens complémentaires de protection des ordinateurs personnels augmente, et les pare-feu gagnent en popularité.

Confronté à cette propagation de pare-feu, les auteurs de programmes malveillants commencent à utiliser de plus en plus activement les leaktests pour contourner ces pare-feu. Vous trouverez ci-après des exemples d’authentiques programmes malveillants qui utilisent chacune des six méthodes principales d’organisation de leaktests.

№№ Méthode Programme malveillant Date de détectio Description
1 Substitution Backdoor.Win32.Bifrose.aer 26 mars 2007 Se copie au lieu du programme MSN Messenger («C:Program FilesMSN Messengermsnmsgr.exe»).
2 Lancement avec les paramètres de la ligne de commande Trojan-Spy.Win32.Agent.se 26 juillet 2007 Lance Internet Explorer avec une fenêtre invisible et transmet dans la ligne de commande le chemin d’accès au fichier HTML.
3 Insertion de bibliothèque dynamique Trojan-Spy.Win32.Goldun.pq 11 janvier 2007 Crée un flux dans le processus winlogon.exe et envoie les données sur Internet via ce flux.
4 Insertion de code dans un processus de confiance Trojan-Spy.Win32.Delf.uc 19 janvier 2007 Crée un flux dans le processus winlogon.exe et envoie les données sur Internet via ce flux.
5 Administration du navigateur Internet Trojan-PSW.Win32.LdPinch.bix 4 janvier 2007 Utilise l’interface COM IwebBrowser2 pour l’envoi des informations récoltées.
6 Utilisation des services systèmes Trojan-Downloader.Win32.Nurech.br 8 juin 2007 Grâce au service système BITS, il envoie sur Internet les données qui identifient l’utilisateur (numéro de série du disque).

Il faut noter que divers types de leaktests conviennent à diverses tâches et ces tests sont utilisés dans les programmes malveillants pour remplir plusieurs objectifs. Plus particulièrement :

  • Via les paramètres de la ligne de commande du navigateur, il est possible de transmettre uniquement un ensemble restreint de données mais l’utilisation de la technologie BITS du programme malveillant permet d’extraire des fichiers de très grande taille de l’ordinateur de l’utilisateur ;
  • Les méthodes d’insertion d’une bibliothèque dynamique ou d’un code logiciel dans un processus de confiance ne sont pas des méthodes propres au contournement des pare-feu car elles permettent d’organiser non seulement l’envoi caché de données au nom d’un processus de confiance mais également d’exécuter de nombreuses autres opérations ;
  • L’utilisation des interfaces pour l’administration du navigateur (par exemple, WebBrowser control) permet non seulement de transmettre les données au nom d’Internet Explorer mais également d’administrer une copie du navigateur (par exemple, fermer toutes les fenêtres dont l’adresse ne répond pas à des conditions définies), de modifier le document chargé dans ce navigateur, d’afficher des fenêtres avec des messages dans le navigateur, etc.

Leaktests

Le tableau ci-après reprend les leaktests connus à l’heure actuelle ainsi que les méthodes qu’ils utilisent. La majorité de ces tests peut être téléchargée depuis les sites :

№№ Nom Auteur Méthode Année
1 AWFT [6] José Pascoa Code injection 2005
2 BITSTester Tim Fish System services 2006
3 Breakout Volker Birk Browser services [s/o]
4 Breakout2 Volker Birk System services [s/o]
5 Coat David Matousec Substitution 2006
6 CopyCat «Bugsbunny» Code injection [s/o]
7 CPIL Comodo Code injection 2006
8.1 CPILSuite [1] Comodo Code injection + Launching 2006
8.2 CPILSuite [2] Comodo DLL injection + Launching 2006
8.3 CPILSuite [3] Comodo DLL injection + Browser services 2006
9 DNStest Jarkko Turkulainen Code injection 2004
10 DNStest Jarkko Turkulainen System services 2004
11 FireHole Robin Keir DLL injection 2002
12 FPR (38) David Matousec [unhooking] [s/o]
13 Ghost Guillaume Kaddouch Launching [s/o]
14 Jumper Guillaume Kaddouch DLL injection 2006
15 LeakTest Steve Gibson Substitution 2002
16 OSfwbypass Debasis Mohanty Browser services 2005
17 pcAudit Internet Security Alliance DLL injection 2002
18 pcAudit2 Internet Security Alliance DLL injection [s/o]
19 PCFlank www.pcflank.com Browser services 2006
20 Runner David Matousec Substitution 2006
21 Surfer Jarkko Turkulainen Browser services 2004
22 Thermite Oliver Lavery Code injection 2003
23 TooLeaky Bob Sundling Launching 2001
24 Wallbreaker [4] Guillaume Kaddouch Launching 2004
25 YALTA Soft4ever [default rules] 2001
26 ZAbypass Debasis Mohanty Browser services 2005

Le tableau suivant offre une répartition des différents tests selon notre classification :

№№ Technologie Leaktests
1 Substitution Coat, LeakTest, Runner
2 Launching Ghost, TooLeaky, Wallbreaker
3 DLL injection CPILSuite [2, 3], FireHole, Jumper, pcAudit, pcAudit2
4 Code injection AWFT, CopyCat, CPIL, CPILSuite [1], DNStest, Thermite
5 Browser services Breakout, OSfwbypass, PCFlank, Surfer, ZAbypass
6 System services BITSTester, Breakout2, DNStester

Signification des résultats des leaktests

Quel est l’intérêt des tests comparatifs des ordinateurs personnels à l’aide de leaktests ?

A l’heure actuelle, lorsque l’utilisateur choisit le système de protection de son ordinateur, il s’intéresse principalement à des éléments tels que le niveau de détection et la vitesse de réaction (par exemple, selon les tests av-comparatives.org, av-test.de). Cela est toutefois insuffisant pour analyser la qualité des systèmes de protection moderne. La qualité du composant proactif de l’antivirus, l’efficacité de la réparation de la machine infectée, la résistance face aux outils de dissimulation d’activité, la qualité de l’autodéfense du logiciel sont des exemples de caractéristiques toute aussi importante qui sont malheureusement ignorées par les auteurs des tests comparatifs. Lors de la sélection d’un logiciel de protection sophistiqué, il faut également analyser les composants complémentaires tels que le système de protection contre le courrier indésirable et le pare-feu.

La qualité du pare-feu est jugée selon deux critères : le contrôle des données entrantes et le contrôle des données sortantes. Un pare-feu qui obtient de bons résultats dans les tests du contrôle des données sortantes est un pare-feu qui n’est pas simplement un ajout à l’antivirus mais bien un niveau de protection complémentaire qui peut empêcher, par exemple, l’envoi de données confidentielles de l’utilisateur aux individus mal intentionnés même lorsque l’antivirus n’a pas intercepté le cheval de Troie.

A notre avis, les produits qui ont obtenu les résultats « Very good » (très bon) et « Excellent » (excellent) à l’issue des tests sur le niveau de protection contre les fuites (matousec.com) garantissent une bonne protection pour l’utilisateur. Lorsque le produit obtient la note « Good » (bon), « Poor » (médiocre) ou « Very Poor » (très médiocre), l’auteur du programme malveillant peut choisir n’importe quel moyen pour contourner le pare-feu de ce produit.

Conclusion

Dans les conditions actuelles, le pare-feu est devenu un élément incontournable des systèmes de protection sophistiqués. Même les systèmes d’exploitation les plus récents tels que Windows Vista ne peuvent bloquer à eux seuls tous les types de leaktests (depuis Windows XP SP2, le système d’exploitation Windows propose un pare-feu dont les fonctions ont été considérablement élargies avec l’arrivée de Windows Vista).

A l’issue des tests réalisés en mars 2007 par Guillaume Kaddouch, seuls 9 leaktests ont été bloqués par Windows Vista Ultimate 64-bit dans une installation par défaut (les tests bloqués apparaissent en gras dans le tableau ci-après).

№№ Nom Remarque
1 Substitution Coat, LeakTest, Runner
2 Launching Ghost, TooLeaky, Wallbreaker
3 DLL injection CPILSuite [2, 3], FireHole, Jumper, pcAudit, pcAudit2
4 Code injection AWFT, CopyCat, CPIL, CPILSuite [1], DNStest, Thermite
5 Browser services Breakout, OSfwbypass, PCFlank, Surfer, ZAbypass
6 System services BITSTester, Breakout2, DNStester

Il ne fait aucun doute que le système d’opération est mieux protégé grâce aux nombreuses améliorations telles que UAC, IE protected mode, Service hardening et Kernel Patch Protection (Vista x64). Toutefois, pour offrir un niveau de sécurité souvent contre ces tests, même Windows Vista doit utiliser des programmes de protection complémentaires.

A l’avenir, les programmes malveillants vont utiliser de nouvelles méthodes pour contourner les mécanismes de protection des nouveaux systèmes d’exploitation et des systèmes de protection existants. C’est pour cette raison que le rôle du pare-feu en tant que niveau complémentaire de protection ne va qu’augmenter. Les auteurs de programmes malveillants vont quant à eux utiliser de plus en plus souvent des technologies de leaktests pour contourner les pare-feu. Dans ces conditions, le recours aux leaktests en tant qu’outil pour vérifier la fiabilité de la protection de l’ordinateur devient incontournable.

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *