S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 19 juin 2009
N° CERTA-2009-ACT-025
Affaire suivie par: CERT-FR
le 19 juin 2009

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-25

Gestion du document

Référence CERTA-2009-ACT-025
Titre Bulletin d’actualité 2009-25
Date de la première version 19 juin 2009
Date de la dernière version 19 juin 2009
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Procédures de départ d’un employé

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.

1.1 Nettoyer les comptes de messagerie

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.

1.2 Changer les mots de passe

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.

1.3 Supprimer les éventuels accès distants

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).

2 Serveurs Web et capacité de délivrer un service

2.1 Actualité

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 :

  • Envoyer une information content-length dans l’en-tête dont la valeur indiquée est plus importante que les données effectivement envoyées ;
  • demander de conserver la connexion en ajoutant régulièrement un keep-alive dans l’en-tête ;
  • etc.

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.

2.2 Principe

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.

2.3 Recommandations

2.3.1 Filtrage HTTP

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.

2.3.2 Filtrage réseau

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).

2.3.3 Configuration du serveur Web

Pour Apache, il est, par exemple, possible dans la configuration d’ajuster les valeurs suivantes :

  • MaxClients : il s’agit du nombre maximal de connexions (sessions) gérées simultanément ;
  • MaxRequestsPerChild : il s’agit du nombre maximal de requêtes qu’un processus peut traiter (child server process) ;
  • ThreadsPerChild : il s’agit du nombre de threads par processus ;
  • MaxSpareThreads : il s’agit du nombre maximal de threads inactifs ;
  • LimitRequestFields : il s’agit du nombre maximal de champs acceptés dans l’en-tête envoyé par un client.
  • etc.

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é.

2.3.4 Architecture

La meilleure prévention contre cette catégorie d’attaques consiste à renforcer l’architecture Web. Il est possible de considérer l’utilisation :

  • d’un pare-feu applicatif qui transfère uniquement les requêtes complètes au serveur ;
  • d’un serveur frontal permettant d’équilibrer les charges (load balancers) ;
  • de serveurs de cache frontaux.

2.4 Conclusion

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.

2.5 Documentation

3 WebCam et systèmes embarqués

3.1 Présentation

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.

3.2 Recommandations

Avec ce type d’équipement, il est donc indispensable d’appliquer une politique de sécurité rigoureuse, comme tout ordinateur ou autre système du réseau :
  • Adapter la politique de filtrage ;
  • appliquer de façon systématique les mises à jour éventuelles ;
  • disposer si cela est possible d’une politique de journalisation prenant en compte ce type d’équipement.

Rappel des avis émis

Dans la période du 08 au 14 juin 2009, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 19 juin 2009
    version initiale.