Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2009-ACT-025
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 19 juin 2009 No CERTA-2009-ACT-025 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2009-25
| Conditions d'utilisation de ce document : | http://www.certa.ssi.gouv.fr/certa/apropos.html |
| Dernière version de ce document : | http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-025 |
Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-025.pdf
Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-025/
Lorsqu'un employé quitte sa fonction, il doit généralement suivre un certain nombre de procédures comme la remise du matériel informatique utilisé, la résiliation des badges d'accès, etc. Toutefois, d'un point de vue informatique, ces procédures sont souvent incomplètes, ce qui peut avoir des conséquences en termes de sécurité. Nous passons ici en revue quelques étapes qui ne sont pas toujours correctement traitées.
Les comptes de messagerie constituent un enjeu important. En effet, il est fréquent qu'après le départ d'un employé, celui-ci continue de recevoir des messages professionnels. Si le compte n'a pas été invalidé, son correspondant peut croire que le message est correctement parvenu à son destinataire, et attendre une réponse qui ne viendra jamais. Par ailleurs, la boîte aux lettres d'un compte qui n'a pas été désactivé peut continuer à grossir, jusqu'à atteindre les limites de quota (si elles existent), ce qui encombre inutilement le disque dur (et dans les pires cas, cela peut engendrer une saturation du disque).
Il est important également de bien se désinscrire de toute liste de diffusion, afin d'éviter des envois inutiles de messages.
Le changement des mots de passe est une étape souvent oubliée ou ignorée après un départ de personnel. En effet, il est possible que l'employé ait partagé un compte commun de connexion avec des collègues, éventuellement sur un service disponible via l'Internet. Dans ce cas, cet employé, bien que ne travaillant plus pour sa société, est susceptible d'avoir des accès à ce compte. La presse a récemment relaté des cas de personnes licenciées qui ont exploité des accès ainsi oubliés pour se venger.
Par nécessité de service, certaines entreprises mettent en place des accès distants pour leurs employés (par exemple dans le cas du télétravail depuis un domicile). Il est évidemment important de penser à fermer de tels accès, ainsi que de passer en revue les règles de filtrage (par exemple, retirer les autorisations de mettre à jour un site Web).
Un outil a récemment fait l'objet de plusieurs discussions sur l'Internet. Il s'agit d'un code qui perturbe le service Web rendu par un serveur.
Il existe bien entendu plusieurs façons de tirer profit des ressources limitées d'un serveur. Ce dernier présente un ensemble de paramètres d'ajustement mais qui s'avèrent être dans certains cas peu ou pas satisfaisants dans le cadre d'attaques en déni de service.
A valeur d'exemple, Il existe plusieurs manières envisageables de perturber le serveur, comme :
Des outils de tests de performance et de charge Apache (branche 1.x) peuvent également être utilisés de bonne ou mauvaise manière. Ils fonctionnent de la même façon.
Plus simplement, plusieurs centaines d'ouvertures de sessions TCP adressées au serveur peuvent également affecter son fonctionnement. Elles ne seront pas nécessairement visibles dans les journaux de l'application, si aucune requête HTTP n'est émise.
Le lecteur comprendra ici que les manières de submerger un serveur Web sont multiples. Nous décrivons dans la section suivante la méthode proposée qui fait l'objet de l'outil en question. Mais les bonnes pratiques et la gestion du risque restent plus généraux que pour cette seule méthode.
L'attaque tire profit d'une fonctionnalité protocolaire concernant des requêtes HTTP incomplètes. Elle consiste simplement à laisser un client envoyer toutes les informations de sa requête (GET/POST/etc.) en plusieurs trames.
Selon les configurations des serveurs Web, ceux-ci peuvent entreprendre de réserver des ressources substancielles dès la réception de la première trame de requête incomplète en perspective de sa réponse, tout en attendant les données manquantes.
L'attaque consiste ainsi à créer plusieurs sessions HTTP en parallèle et envoyer pour chacune d'elles une requête incomplète. Puis, dans un délai de l'ordre de quelques minutes, ces requêtes sont maintenues par des données additionnelles mais sans jamais compléter totalement l'en-tête de la requête.
Tout service Web qui gère les sessions incomplètes de la manière précédente sont potentiellement vulnérables, sans autre contrôle adapté. C'est le cas des serveurs Apache (versions 1.x et 2.x) et de la passerelle Squid. Microsoft IIS 6.0 et 7.0 ne sont pas affectés.
L'attaque ne permet cependant pas d'usurper simplement des adresses IP émettrices arbitraires, car les sessions TCP sont établies.
Certains articles signalent que l'outil a une « signature » particulière. En effet, son en-tête HTTP est de la forme :
GET / HTTP/1.1
Host: leServeurCible
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
.NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729; MSOffice 12)
Content-Length: 42
X-a: b
L'information " X-a: b" est celle envoyée à intervalles de temps réguliers pour prévenir le serveur que l'en-tête continue d'être émis. Elle ne veut rien dire de particulier. Il n'y a pas de ligne vide précisant la fin de l'en-tête (code retour de fin ligne - CRLF - seul).
Il est donc possible de chercher et couper toute connexion de machine ayant cette caractéristique. Néanmoins cette méthode ne reste adaptée qu'à cette variante de l'outil et il est très simple de la modifier (simple édition d'un script). Il en va de même pour la valeur du User-Agent.
Autre caractéristique de l'outil : il cherche à ouvrir plusieurs sessions HTTP (sockets) en parallèle. Cela se caractérise donc dans un intervalle de temps très court par de multiples demandes de connexion TCP adressées au serveur. Un pare-feu en amont peut, de manière préventive, limiter le nombre de sessions TCP ouvertes par adresse IP distincte. Cette approche peut avoir des effets de bord sur du trafic légitime (translation d'adresse et partage d'une même adresse IP publique par plusieurs machines, ou utilisation d'une passerelle inverse (reverse proxy) qui serait la seule adresse IP vue par le serveur).
Pour Apache, il est, par exemple, possible dans la configuration d'ajuster les valeurs suivantes :
Les paramètres MaxClients et MaxRequestsPerChild ne changent pas grand chose à la réussite de l'attaque. LimitRequestFields peut lui réduire la durée d'une tentative mais l'attaquant a toujours la possibilité de recommencer l'opération depuis le départ.
Plusieurs suggestions ont été faites et sont effectivement envisageables, comme la notion d'un minuteur dynamique (dynamic timer) pour la durée des sessions dont la valeur est choisie en fonction de la charge réelle du serveur.
Des modules tiers à ajouter au serveur peuvent aider à se défendre dans le cadre de cette attaque. Il faut cependant être très vigilant avec ces codes qui sont pas nécessairement audités proprement, qui peuvent prendre des initiatives (activations de règles de pare-feu) et qui peuvent être eux même directement ciblés. Leur usage n'est donc pas conseillé.
La meilleure prévention contre cette catégorie d'attaques consiste à renforcer l'architecture Web. Il est possible de considérer l'utilisation :
Cette attaque est intéressante mais s'ajoute aux autres méthodes existantes et relativement semblables pour perturber un service Web en ligne.
Il n'existe pas de mesure « universelle » permettant de se protéger des attaques en déni de service. En revanche, il est important d'estimer le risque et de préparer préventivement un certain nombre de mesures dans le cas où certaines tentatives seraient tentées contre un site.
http://www.w3.org/Protocols/HTTP/
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
Les webcams sont devenues une option courante sur les ordinateurs personnels récents, en particulier sur les ordinateurs portables où ils sont, le plus souvent, intégrés dans l'entourage de l'écran. Le CERTA a déjà pu aborder les risques associés à ce type de technologie en particulier dans un contexte de messagerie instantanée (CERTA-2008-ACT-46, CERTA-2007-ACT-38).
Sont apparues plus récemment, des webcams non plus asservies à un ordinateur mais pourvues d'un système embarqué complet les rendant totalement autonomes. Il existe ainsi des modèles disposant d'une pile IP complète leur permettant de communiquer via un réseau filaire ou bien en Wi-Fi. Sur certaines autres, on peut également trouver des fonctions d'enregistrement local.
Ces nombreuses fonctionnalités ne peuvent être
mises en 
uvre que par l'intermédiaire
d'un système d'exploitation embarqué capable, par
exemple, d'enregistrer sur un support numérique type
SD-CARD ou bien encore d'envoyer des flux vidéo
et audio sur IP vers une centrale d'enregistrement.
Or, comme tout système, il peut être
vulnérable et constituer un point d'entrée
privilégié pour certains attaquants car
facilement identifiable et rarement mis à jour.
Dans la période du 12 au 19 juin 2009, le CERTA a émis les avis suivants :
Durant la même période, les trois avis suivants ont été mis à jour :
(ajout des références aux bulletins de sécurité Fedora et Sun)
(ajout des références aux bulletins de sécurité VMware et)
(ajout des références aux bulletins de sécurité Mandriva, HP et Suse)