Précédent Remonter Suivant

Chapitre 13  Sécurité

La sécurité informatique peut se prévaloir de plusieurs définitions. Nous avons déjà vu comment Unix protège ses utilisateurs (mémoire protégée, droits d'accès). On peut se prémunir de dangers liés à la disparition de fichiers (sauvegardes, systèmes de miroir, etc.).

On peut également souhaiter protéger l'utilisateur contre les programmes bogués. On peut essayer pour cela d'en vérifier les propriétés de façon statique ou dynamique, par des techniques de preuve de programmes, ce qui éviterait les désagréments des divers programmes embarqués livrés au grand public. On parle là plus sûrement de sûreté.

La sécurité des réseaux est un autre sujet. Là, on peut vouloir éviter d'être espionné, ou bien tout simplement être sûr que les fichiers transférés ne sont pas altérés (sciemment ou non). Un bon protocole comme TCP peut être vu comme plus résistant que UDP, car effectuant un minimum de contrôle sur les données transmises.

Nous allons dans ce chapitre insister sur deux points: le filtrage des données par un parefeu (firewall) et les problèmes liés aux virus.

13.1  Parefeu et filtrage de paquets

Un domaine comme celui de polytechnique.fr prend souvent l'allure de la figure 13.1: une enceinte protège les machines qui se trouvent à l'intérieur, et les accès vers et depuis l'extérieur sont contrôlés par un parefeu.


Figure 13.1 : Un réseau typique.




Un parefeu (firewall) permet de filtrer toutes les données en entrée (accès, mail, etc.). Il fait de plus en plus souvent du filtrage de paquets. Commençons par décrire quelques attaques classiques.

13.1.1  Attaque par submersion

Regardons ce qui se passe à bas niveau quand deux machines veulent établir une connection entre elles. Le protocole de connection est le suivant: A envoie une requête de connection SYN accompagnée d'un numéro de session X. B répond par le même message accompagné d'un numéro Y, et un accusé de réception de X. A termine l'établissement de connection en accusant réception de Y. L'intérêt de X et Y est de pouvoir identifier une session par son numéro. Ce sont hélas des numéros assez faciles à prévoir. Cela permet de lancer une attaque classique, appelée submersion (flooding).

Pour ce faire, C envoie des milliards de demandes de connection au serveur, mais ne renvoie jamais le dernier ACK(Y), ce qui bloque le serveur, qui ne peut plus accepter de connections. Une défense possible est de programmer le parefeu pour qu'il coupe les connections en attente depuis trop longtemps.

13.1.2  Spoofing

Dans cette attaque, C veut se faire passer pour A auprès de B. C fabrique un message TCP qui ressemble à un message émanant de A (avec le numéro IP de A) et envoie SYN(X) à B. Si C devine Y, il renvoie ACK(Y) à B et donc établit la connection. C doit empêcher le message SYN-ACK(Y) d'arriver à A, par exemple en submergeant A.

Comment contrer une telle attaque? Le plus simple est de rendre X et Y non devinables, mais ce n'est pas si simple. Souvent C est une machine extérieure qui essaie de se faire passer pour une machine interne auprès d'un routeur de sortie. Il suffit donc de ne pas autoriser une machine interne à passer par l'extérieur. Une vraie défense est d'utiliser des techniques d'authentification cryptographique, mais c'est là une solution assez lourde.

13.1.3  Le filtrage des paquets

Pour se protéger d'accès indésirables (trous de sécurité liés à certains programmes qui écoutent certains ports), il est prudent de filtrer les paquets, en entrée de site, comme chez soi (ADSL). Même si scanner tous les ports d'un ordinateur est un casus belli dans beaucoup de sites, il faut néanmoins arriver à contrôler ceux qui le font.

On édite alors des règles de filtrage, comme par exemple celles du tableau qui suit:
Ainsi, on autorise tous les paquets à destination de la machine de numéro IP 123.4.5.6 à passer, à condition qu'ils soient à partir de ports de numéros élevés vers le port 23. De même, la machine de numéro IP 123.4.5.7 peut recevoir du courrier sur le port 25. Seule la machine de numéro IP 129.6.48.254 peut envoyer des paquets sur le port 119 de la machine 123.4.5.6. Tout autre paquet est interdit et rejeté.

13.2  Les virus

On suit ici de près le livre d'É. Filiol [Fil03]. Les virus sont responsables de beaucoup de problèmes sur les ordinateurs particuliers (surtout ceux fonctionnant sous les systèmes de Microsoft, pour des raisons techniques complexes, voir la référence en question).

Commençons par donner une définition des virus.
Définition 2   Un virus est une séquence de symboles qui, interprétée dans un environnement adéquat, modifie d'autres séquences de symboles dans cet environnement, de manière à y inclure une copie de lui-même, copie ayant éventuellement évoluée.

Notons tout de suite que la définition n'implique pas que le virus soit dangereux ou malveillant. Il existe des exemples (étranges) de virus bienveillants (!).

Le mode de fonctionnement typique d'un virus est le suivant: un déclencheur (programme trop intelligent; utilisateur peu dégourdi) permet le démarrage de l'infection; le virus infecte alors les fichiers et peut se répandre.

Il y a encore quelques années, l'infection se faisait par échange de disquette. Aujourd'hui, la propagation se fait par le réseau, ce qui la rend plus dangereuse. Cela demande également plus de connaissances au pirate, mais aussi aux fabricants d'anti-virus.

13.2.1  Brève histoire (d'après É. Filiol; O. Zilbertin)

Il semble que le premier virus informatique répertorié soit apparu en 1981 par accident à Xerox, et ce sur un Apple II. En 1983, le virus Elk Cloner pour AppleDOS 3.3 se répand. En 1986, le premier travail scientifique sur les virus parait. Il s'agit de la thèse de Fred Cohen, un élève de Len Adleman (le A du fameux système de chiffrement RSA). C'est d'ailleurs lui qui invente le terme virus. En 1988 se répand le premier (et le seul) virus malveillant connu sur Internet (le ver, voir plus bas). En 1991, Frodo/4096 arrive par l'intermédiaire d'une disquette vendue dans la revue Soft et Micro.

En 1998, on estime à 17745 le nombre de virus différents recensés, contre 18 en 1989. L'un des virus récents ayant défréné la chronique est le célèbre "I love you" de l'an 2000.

Intéressons-nous de plus près au ver internet [Spa89]. Son auteur est connu, il s'agit de Robert T. Morris, Jr, qui a finalement été condamné en 1991 à trois années de probation, 400 heures de travaux d'intérêt général et 10,000 $ d'amende. Le virus utilisait des bogues de type buffer overflow dans les programmes standard Unix, que sont sendmail, finger. Son principe d'infection était le suivant: une fois lancé, le programme cherchait des comptes utilisateur avec des mots de passe faibles à l'aide d'un craquage simple. Une fois les comptes infectés à leur tour, le virus tentait de se propager au moyen de commandes d'exécution à distance du type rsh, rexec. Le virus utilisait également des techniques de furtivité (effacement des arguments, dissimulation du nom du programme, fork, etc.).

La communauté Internet a réagi de la façon suivante. Le fichier /etc/passwd a été progressivement remplacé par un fichier caché non accessible pour les utilisateurs (/etc/shadow), et le programme rsh par des versions sécurisées type ssh. Le virus a également révélé des problèmes dans la gestion d'une telle crise transnationale. La crise a commencé le 2 novembre 1988, et n'a été résolue que le 8 novembre. Couper Internet pendant une telle période était envisageable à l'époque, plus du tout maintenant. Le CERT est né de cette crise, et il régule et informe très vite de l'apparition des nouveaux virus. En 1988, le mail a été coupé tout de suite pour éviter la propagation, ce qui dans le même temps a empêché la diffusion des solutions pour éradiquer le virus...

13.2.2  Le cas de Nimda

Nous donnons cet exemple pris toujours dans le même livre de Filiol, comme représentatif d'un virus "moderne".

Ce virus a été découvert le 18 septembre 2001, et il attaquait les systèmes Windows*. Il utilisait deux trous de sécurité : Unicode exploit pour infecter les serveurs IIS et MIME exploit. Son cycle de vie était le suivant:
  1. Infection des fichiers: le virus localise les fichiers EXE et les assimile, puis se propage par échange de fichiers (mode classique).
  2. Envoi massif de courriels: Nimda récupère des adresses mail dans le client de courrier et dans les pages html; il envoie alors un courrier à toutes les adresses avec un fichier README.EXE en attachement (grand classique).
  3. Attaque des serveurs web: il recherche les serveurs web proches; quand il en trouve un, il essaie d'y entrer avec l'un des trous de sécurité connus. S'il y arrive, il modifie des pages web au hasard avec pour résultat d'infecter les surfers.
  4. Propagation par les réseaux locaux: en cas de fichiers partagés, crée un fichier RICHED20.DLL qui sera activé par Word, etc., ce qui provoquera une infection de la machine distante au moment de l'activation.

13.2.3  Un peu de théorie

Le théorème suivant est fondamental.
Théorème 3  [F. Cohen, 1986]   Détecter un virus par analyse syntaxique est un problème indécidable.

Démonstration: supposons qu'il existe une fonction Detecte(fonction_java), on construit:
  static void f(){
    if(! Detecte(f))
      infecter();
  }
alors on se retrouve devant le même argument qui dit qu'on ne peut détecter les programmes qui ne terminent pas.

Ce théorème est important, car il explique qu'on ne pourra jamais détecter un virus nouveau de façon syntaxique pure. Par contre, une fois identifié par une signature particulière, on pourra le reconnaître par consultation d'une base de données de virus à jour (un morceau d'un antivirus). On soigne, mais on ne prévient pas l'infection.

13.2.4  Conclusion sur les virus

On peut considérer que la menace des virus sera de plus en plus présente dans l'avenir (téléphones mobiles). On voit arriver des attaques de plus en plus professionnelles, avec des buts de plus en plus divers (spam). Et bien sûr, les nouveaux virus seront de plus en plus difficiles à éradiquer (virus de BIOS, binaires, etc.).

13.3  En guise de conclusion: nouveaux contextes = danger

D'un point de vue général, et ce de façon très triste, la sécurité n'est jamais parfaite quand un nouveau produit apparait. Celle-ci est très souvent rajoutée a posteriori, quand des problèmes sont apparus. Citons par exemples les problèmes liés au WiFi, ces réseaux souvent déployés sans contrôle, avec des protocoles de sécurité inexistants au départ, mais améliorés récemment.


Précédent Remonter Suivant