Été chaud pour la sécurité informatique
Code Red et Sircam nous rappellent quelques règles d'or

Martin.Ouwehand@epfl.ch, SIC

Deux événements récents dans le domaine de la sécurité informatique nous ont empêché de sombrer dans l'habituelle torpeur estivale. Tout d'abord, Sircam est un représentant de cette famille de virus qui fait la une des journaux deux à trois fois par année (nous avons déjà eu Melissa, ILoveYou, Hybris, HomePage, etc.) et qui se transmettent comme attachment de messages E-mail au titre aguichant ou au contenu titillant la curiosité de l'utilisateur naïf qui, en cliquant là où il ne faudrait pas, permet au virus de s'exécuter et d'envoyer une copie de lui-même aux personnes qu'il trouve dans le carnet d'adresse ou qu'il renifle même directement sur les connexions réseau. Sircam nous rappelle la première règle d'or de la sécurité informatique:

Se prémunir des virus

ceci se fait en installant sur son poste de travail (PC/Windows ou Macintosh) un logiciel anti-virus et en tenant régulièrement à jour la base de données des signatures de virus. Pour plus de détails, suivre les indications que vous trouverez sous ces URL:

http://slwww.epfl.ch/SIC/SL/securite.html#winu

http://slwww.epfl.ch/SIC/SL/securite.html#macu

De plus, il ne faut jamais exécuter les attachments nous arrivant par courrier électronique, même s'ils paraissent provenir d'un correspondant connu ou traitant d'un Subject familier: de nos jour, il n'y a guère plus de virus se transmettant par E-mail qui ne soient capables de faire figurer dans le message qu'ils nous envoient ce genre de renseignements destinés à endormir notre méfiance.

Si Sircam est un virus (il a besoin d'une intervention extérieure, tel qu'un utilisateur exécutant l'attachment, pour se propager) Code Red est de son côté un ver, c'est-à-dire qu'il se répand de lui-même, sans intervention extérieure, en utilisant une vulnérabilité des ordinateurs qu'il infecte. Dans le cas de Code Red, ce point faible est une version non mise à jour d'IIS (Internet Information Services, le logiciel de serveur Web pour Windows de Microsoft). Chaque serveur infecté va scanner Internet à la recherche d'autres serveurs vulnérables à infecter, qui eux même vont en infecter d'autres, etc. On estime que Code Red a atteint de cette manière environ 250'000 serveurs en moins de 9 heures entre le 19 et le 20 juillet (voir http://www.cert.org/advisories/CA-2001 -23.html). Code Red est sans doute le cas de piratage le plus grave qu'Internet ait connu depuis le ver de Morris en 1988, voir:

ftp://sunsite.cnlab-switch.ch/doc/standard/rfc/11xx/1135

http://www.cert.org/encyc_article/tocencyc.html#History

et son auteur aurait facilement pu rendre Internet inutilisable pendant quelques jours s'il avait confié à son ver une tâche plus destructrice que de simplement surcharger le site de la Maison Blanche (dont les responsables ont contourné le problème simplement en changeant son adresse IP). Pour plus de précisions au sujet de Code Red, voir:

http://www.cert.org/advisories/CA-2001-23.html

L'EPFL n'a pas été épargnée par Code Red, d'abord par la version plus bénigne du 19 juillet qui a touché 85 machines, suivi de Code Red II qui a touché une quinzaine de machines à partir du 4 août. Cette dernière version est plus méchante que la première puisqu'elle laisse des portes dérobées (backdoor en jargon anglo-informatique), permettant à quiconque sur Internet d'exécuter des commandes à distance sur l'ordinateur touché, et qu'elle essaye d'infecter en premier lieu son voisinage réseau (donc dans notre cas, d'autres machines de l'EPFL). C'est parce que nous avons fermé l'accès Internet des machines infectées par la première version de Code Red qu'il y a eu relativement moins de victimes de la version II.

Lorsque nous avons essayé d'alerter les administrateurs concernés, nous avons rencontré les difficultés habituelles de dissémination de l'information dans notre site, très étendu, à la gestion informatique très décentralisée et où les bottins d'administrateurs de machines sont toujours désespérément incorrects ou dépassés. Dans ces conditions, il est nécessaire que les utilisateurs de moyens informatiques, et en tout premier lieu les administrateurs, suivent la deuxième règle d'or de la sécurité informatique:

Se tenir informé

ceci concerne d'abord l'information de fond, pour laquelle un point d'entrée est la page de sécurité informatique du SIC:

http://slwww.epfl.ch/SIC/SL/securite.html

qu'il est judicieux de visiter de temps en temps, puisqu'elle est régulièrement mise à jour. Ensuite, pour les informations urgentes telles que les alertes ou les annonces de correctifs, il faut lire au moins une fois par semaine, mais de préférence quotidiennement, le forum des News epfl.comp.securite . Les forums News ont parfois mauvaise réputation (on y perd son temps), mais dans le domaine de la sécurité informatique ils ont l'avantage que chacun peut demander des précisions sur des points obscurs ou apporter sa contribution en rapportant ses expériences, en signalant les points délicats liés à telle ou telle situation, etc. L'utilisation des News en général est documenté ici:

http://ditwww.epfl.ch/SIC/SA/News/Intro_News.html

En considérant cette centaine de serveurs IIS touchés, on se pose la question: servaient-ils vraiment à quelque chose? Alors que certains d'entre eux étaient effectivement configurés comme serveur Web d'unité, il semble que dans beaucoup de cas ces serveurs tournaient suite à une installation par défaut du système d'exploitation Windows mais qu'ils ne servaient à rien du tout, en infraction avec la troisième règle d'or de la sécurité informatique:

Limiter les services réseau au strict minimum

Les trous de sécurité dans les services réseau (qui écoutent en permanence sur un port réseau en attendant une connexion d'un client) sont de loin les plus graves, parce qu'on peut les exploiter à distance, parfois depuis n'importe quel ordinateur du monde connecté à Internet - c'est exactement ce qui s'est passé avec Code Red, des centaines de milliers de fois ! On diminue grandement le risque de piratage en ne laissant tourner que les services réseau strictement nécessaires, qui remplissent effectivement une tâche utile aux utilisateurs de l'EPFL. Les administrateurs des serveurs doivent donc régulièrement lister ces services (avec l'utilitaire ActivePorts, http://www.smartline.ru/software/aports.zip , sous Windows et avec la commande lsof sous Unix, http://slwww.epfl.ch/SIC/SL/securite.html#lsof ) et désactiver ceux qui ne pas utilisés.

Comme l'a abondamment souligné la presse, l'infection par Code Red n'était pas une fatalité inéluctable contre laquelle on ne pouvait rien faire. Le ver exploitait une vulnérabilité connue du logiciel IIS et pour laquelle Microsoft avait publié un correctif (patch en jargon anglo-informatique) le 18 juin. En suivant donc la quatrième règle d'or de la sécurité informatique:

Tenir à jour les logiciels et appliquer
les correctifs à temps

on aurait pu se prémunir facilement de Code Red, et c'est en fait le cas de nombreuses vulnérabilités: le correctif est disponible avant que les attaques soient très répandues.

Nous arrivons à la dernière règle d'or de la sécurité informatique:

Mettre en place un contrôle d'accès

De quoi s'agit-il ? Après avoir suivi la règle d'or précédente, ne tournent plus sur votre serveur que quelques services réseau. Très souvent, il sont ouverts par défaut au monde entier, alors qu'il n'y a que quelques utilisateurs ou machines qui en sont les clients légitimes. Il s'agit donc de restreindre effectivement l'accès à ces utilisateurs ou à ces machines-là, si c'est possible. Comment le faire dépend de chaque service réseau (sous Unix, il n'y a guère que tcp_wrappers qui offre une solution générique de contrôle d'accès par machine pour tous les services gérés par inetd, voir: http://slwww.epfl.ch/SIC/SL/securite.html#tcp_wrappers ) et je ne peux que renvoyer les administrateurs à la documentation spécifique à chaque logiciel. Notons que cette règle d'or concerne un peu moins que les autres l'incident Code Red: tout au plus, dans le cas de quelques sites Web de test ou d'un intérêt purement interne, aurait-on pu restreindre l'accès à l'EPFL uniquement.

Quelques remarques personnelles en conclusion

Sur le plan de la sécurité informatique, Code Red est un très mauvais point pour IIS quand on le compare à son grand rival Apache, surtout quand on sait que la vulnérabilité exploitée fait suite à d'autres déjà mises en évidence dans l'année passée (par exemple, il y a eu quelques cas de piratage de serveurs IIS à l'EPFL par la Folder Traversal Vulnerability). Ceci n'est pas contestable, mais de là à tirer la conclusion que le logiciel libre est supérieur au logiciel propriétaire en ce qui concerne la sécurité informatique, c'est un point sur lequel je resterai plus prudent: à côté d'Apache, qmail ou OpenBSD, qui ont un très bon historique de sécurité, il y a par exemple bind ou wu-ftpd qui ont eu leur part de problèmes par le passé. Dans la même veine, d'après mon expérience, les utilisateurs Linux ou Unix sont généralement aussi démunis que les utilisateurs Windows pour traiter les problèmes de sécurité, contrairement à ce que prétendent certains. Par exemple dans l'incident imapd de fin 1998 (une vingtaine de machines Linux piratées à l'EPFL) on a vu les mêmes comportements à risque que pour Code Red: services inutiles et patches non appliqués.

Un autre point frappant est que le défaut logiciel qui a rendu le ver de Morris possible en 1988 subsiste encore en 2001 pour Code Red. Dans les deux cas, les pirates ont exploité la même erreur, un débordement de mémoire (buffer overflow en jargon anglo-informatique): le programmeur ne vérifie pas qu'il a réservé assez de place en mémoire avant d'y copier des données provenant de l'extérieur (réseau, données entrées par l'utilisateur) et un pirate peut placer dans les octets surnuméraires des instructions soigneusement combinées pour qu'elles soient exécutées par l'ordinateur vulnérable. Ce type d'erreur est, de nos jours encore, à l'origine de la grande majorité des problèmes de sécurité. Pourtant, il est possible de l'éviter de plusieurs manières: en confiant la tâche à des programmeurs soigneux (c'est le cas des exemples cités ci-dessus: Apache ou qmail) ou, ce qui revient au même, en les formant correctement, en soumettant le code source à un audit systématique (OpenBSD est un succès notoire dans ce domaine, voir http://www.openbsd.org/) ou peut-être en évitant des langages de programmation à risque, comme C et C++, et en leur préférant par exemple Java, où ce type d'erreurs n'est pas possible. Le prix à payer dans ce dernier cas est un environnement run-time plus lourd et, en l'absence d'une longue tradition, le risque de voir apparaître d'autres types d'erreurs et de vulnérabilités.

C'est à mon avis une manifestation typique de notre société de consommation si les éditeurs de logiciels n'implémentent pas les mesures nécessaires pour éviter ces problèmes de sécurité: ce seraient autant de ressources qu'ils ne pourraient pas investir dans ce qui fait apparemment vraiment vendre, c'est-à-dire des fonctionnalités toujours plus nombreuses et clinquantes, destinées à épater l'acheteur. La situation ne changera donc pas tant que les consommateurs ne feront pas sentir aux éditeurs de logiciels qu'ils tiennent à des logiciels fiables et sûrs, en se détournant de ceux qui n'auront pas fait leurs preuves dans ce domaine. L'industrie informatique attend encore son Ralph Nader (le leader du mouvement de consommateurs au début des années 60 qui avait convaincu l'industrie automobile de fabriquer des voitures plus sûres).


retour au sommaire du Flash informatique du mois de septembre 2001
retour à la page principale des Flash informatique
Vos commentaires
© FI-7-1 du 18 septembre 2001