Ce document est obsolète et ne sera pas mis à jour. Veuillez vous référer aux documentations techniques disponibles sur le site de l’ANSSI : https://www.ssi.gouv.fr/
1 Introduction
La récente vague d’attaques dont ont été victimes un certain nombre de grands sites américains (« Yahoo ! » le 07/02/2000, « Buy.com », « Stamps.com », « eBay », « CNN », « Amazon » et « MSN » le 08/02/200, « ZDNet » et « E*Trade » le 09/02/2000) correspond à des attaques de type déni de service (Denial of Service ou DoS).
Ce document, de type Note d’information, a pour but de présenter ce type d’attaque, de fournir un certain nombre de pointeurs sur des documents de référence et de donner quelques pistes pour tenter de se protéger contre de telles attaques.
1.1 Le principe des attaques
Ces attaques visent à rendre inutilisable un site par une saturation de requêtes (la cible n’est pas compromise) rendue possible par la mise à contribution de centaines de machines piratées à cet effet. Les attaquants recherchent sur le réseau, au moyen d’outils classiques d’analyse, des machines présentant des failles connues qui permettent d’obtenir le privilège administrateur (root) sur ces machines (on peut penser que les campagnes de scans, qui se sont déroulées depuis la fin de l’été sur Internet, avaient pour but de recenser les machines présentant de telles faiblesses).
Une fois le privilège administrateur obtenu, les attaquants installent ensuite sur les machines compromises un logiciel d’attaque, de type client/serveur, qui est piloté depuis une machine unique sous leur contrôle. Le but du jeu étant de disposer de plusieurs centaines de machines disposant de ce logiciel d’attaque. Les outils d’attaque de type déni de service distribué (DDoS, Distributed Denial of Service) sont disponibles sur Internet et certains ont fait l’objet d’une mise à jour récente.
Au moment choisi, il ne reste plus qu’à déclencher une attaque vers une cible unique : cela peut être un envoi massif de mèls, de demandes de recherche d’information (« Yahoo ! »), de commandes (« Amazon »), etc. Les serveurs attaqués sont alors noyés sous un flux d’information extrêmement important (un milliard de bits par seconde dans le cas de « Yahoo ! ») et ne sont plus capables de remplir leur tâche principale : c’est le déni de service.
1.2 Les parades
Il n’existe malheureusement pas de parade pour ce genre d’attaque, en effet on peut facilement détecter une attaque provenant d’une machine unique (correspondant à une même adresse) et bloquer le flux d’information en provenance de cette machine, mais il est très difficile de distinguer, lorsque le flux est réparti sur des centaines de machines, une attaque d’une demande de connexion en provenance d’un client réel. Si le logiciel d’attaque est bien fait, il génère des requêtes qui sont toutes différentes ce qui rend encore plus difficile la détection de l’attaque.
Comme l’a dit Thomas Longstaff de l’université de Carnegie Mellon :
« En réalité, la prévention doit plus porter sur le renforcement du niveau de sécurité des machines connectées au réseau [pour éviter qu’une machine puisse être compromise] que sur la protection des machines cibles [les serveurs Web] ».
Il est indispensable de vérifier régulièrement que les machines ne présentent pas de failles de sécurité et ne pourront pas être utilisées en rebond dans une attaque. Il existe des outils commerciaux et du domaine public qui permettent d’effectuer de telles recherches (ne pas hésiter à contacter le CERTA pour obtenir des informations sur ces outils).
Les recommandations CERTA-1999-REC-001 du 8 décembre 1999 restent bien sûr d’actualité, surtout celle concernant le recueil des traces : « veiller au recueil et à la conservation de toutes les traces liées aux incidents et susceptibles de servir de preuves ultérieurement. Les journaux doivent naturellement être activés et protégés ».
2 Systèmes affectés
2.1 Les systèmes vulnérables au déni de service
Tous les systèmes reliés à Internet sont des victimes potentielles du déni de service. Les services attaqués (courrier électronique, WEB, ICMP, etc.) sont universels.
2.2 Les systèmes vulnérables au rebond
Les systèmes suivants sont connus comme pouvant être des machines servant d’intermédiaires dans les attaques de déni de service :
- Certains Macintosh sous MacOS 9 peuvent servir d’amplificateur de trafic. Une nouvelle version d’Open Transport (2.6) a été publiée pour corriger cette faille, cette nouvelle version est disponible à l’adresse suivante :
http://asu.info.apple.com/swupdates.nsf/artnum/n11560
- Les machines Unix sont sensibles à trinoo, TFN (Tribe Flood Network), TFN2K (Tribe Flood Network 2000) et Stacheldraht ;
- Les machines sous Windows sont sensibles à TFN2K.
3 Comment détecter une attaque ?
3.1 Détecter un déni de service
Un déni de service présente sensiblement les mêmes symptômes que ceux d’un système dont le réglage n’est pas adapté à la charge en présence d’un pic d’utilisation légitime. Si après s’être assuré que les serveurs et le réseau sont correctement configurés, on constate que :
- les serveurs (messagerie, WEB, routeur, …) sont soumis à une charge considérablement au-dessus de la moyenne ;
- le réseau véhicule un trafic anormalement important ;
- on peut alors raisonnablement penser à un déni de service.
3.2 Détecter une compromission
A l’instar des outils de détection de virus :
- tout moyen de détection de déni de service est rapidement obsolète à mesure que les sources des outils d’attaques sont modifiées ;
- un seul examen des systèmes ne suffit pas. Il convient de chercher régulièrement si les systèmes ne sont pas infectés.
3.3 Outils de détection
Le tableau suivant décrit plusieurs outils qui aident à détecter les machines compromises par certains logiciels d’attaque. Ce sont des outils de balayage de réseau (scan) pour y trouver des traces de compromissions. L’OS évoqué concerne uniquement la machine d’analyse et non pas les machines compromises.
|
3.4 L’approche manuelle
Une étude régulière de la configuration de chaque système peut aider à trouver les logiciels DDoS.
- les machines infectées ont probablement été configurées avec un rootkit. Il est possible de reconnaître des programmes infectés en cherchant des chaînes de caractères spécifiques à l’aide de la commandestrings ou bien en étudiant les paquets échangés. Les documents suivants expliquent ce qu’il faut rechercher :
- de manière générale la découverte de chevaux de Troie peut être effectuée aisément à l’aide d’outil commeTripwire mis en oeuvre dès l’installation du système ;
- les machines infectées sont susceptibles d’émettre des paquets IP dont l’adresse origine est falsifiée. Un tel trafic est le signe évident de l’utilisation malveillante d’une des machines du réseau interne. Si ce n’est pas déjà fait, il convient de configurer le routeur ou le firewall afin de détecter les paquets dont l’origine ne correspond pas à l’une des adresses du réseau interne ;
- les ports 1524, 27665, 27444, 31335 et 37337 ont été utilisés pour prendre le contrôle à distance de machines infectées. L’utilisation régulière de logiciels commenessus ounmap permet d’identifier ports ouverts par les machines du réseau interne. L’apparition de nouveaux ports doit faire l’objet d’une enquête.
En cas de découvertes de l’intrusion en vue de commettre un déni de service, les recommandations décrites dans le document CERTA-1999-REC-001 restent applicables.
4 Comment se protéger ?
D’une manière générale il est difficile de se protéger d’une attaque par DoS/DDoS. Néanmoins les règles élémentaires de sécurité complétées par des actions spécifiques permettent de minimiser les effets de ce type d’attaque.
4.1 Règles élémentaires
- Utilisez les dernières versions des logiciels : il est courant de posséder des versions obsolètes des systèmes d’exploitation ou des applications, possédant des trous de sécurité, exploités par les outils DDoS, qui ont depuis été résolus ;
- Souscrire à des listes de diffusion relatives à la sécurité. Tenir à jour les actions à entreprendre en cas d’urgence (conduite à tenir, téléphone..) ;
- Archivez et exploitez efficacement les journaux (stockage extérieur, régularité de l’opération) ;
- Invalidez les services inutiles, en particulier sur les machines bastions.
4.2 Règles spécifiques
- Configurez avec soin les serveurs Web : il est par exemple possible sur les serveursapache de réduire les délais d’expiration des connexions. Cette action aura pour effet d’atténuer les effets de saturation mais risque, dans le même temps, de faire échouer des connexions valides ;
- Multipliez les serveurs et les sites de façon à distribuer les requêtes entrantes : ce partage est réalisable par une méthode simple et efficace comme le Round Robin DNS ou par une solution hardware comme un répartiteur. Il est ainsi possible de configurer deux serveurs DNS, le second servant de secours au premier, de façon transparente, en cas de saturation (en prenant soin de dissocier clairement les adresses IP de ces serveurs) ;
- Paramétrez votre garde barrière afin d’interdire temporairement les adresses IP les plus actives à partir desquelles les attaques sont émises. Une machine rebond pourra souvent être réutilisée avant que son détenteur n’en soit informé et qu’il ne réagisse …
- Paramétrez votre garde barrière afin d’interdire les paquets sortant dont la source n’est pas une adresse IP interne connue : ainsi, au mieux, vous interdirez à une de vos machine de servir de rebond et dans le pire des cas, la cible du DoS pourra identifier le réseau origine du rebond.
5 Outils d’attaque distribuée
5.1 Généralités
Par rapport aux outils traditionnels d’attaque, les outils distribués sont caractérisés par :
- une procédure d’installation de logiciels d’attaque (infection) fortement automatisée pour pouvoir traiter un nombre conséquent de machine ;
- une architecture distribuée de type client/serveur semblable en cela aux logiciels d’administration ou de sécurité des réseaux modernes ;
- une attaque massive de déni de service, coordonnée, par les machines infectées contre un ou plusieurs sites.
L’efficacité du déni de service étant liée au nombre de machines compromises, le programme d’installation recherche (scan) et exploite une ou des failles liée(s) à des services installés de manière standard sur les stations : services RPC de Sun, serveur FTP, … pour s’y introduire frauduleusement. De plus, un root kit est éventuellement installé modifiant les commandes usuelles telles ls, ps, netstat, …, de manière à dissimuler les programmes et connexions réseaux illicites.
Dans les versions les plus récentes l’architecture comporte 3 types d’hôtes différents, le client, le(s) serveur(s) et les agents (terminologie du CERT/CC). Le schéma typique est le suivant :
+---------+
| Client� |
+---------+
|
... --+-------------+-------------+-- ...
|�������������������������� |
+-----------+�������������� +-----------+
|� Serveur� |�������������� |� Serveur� |
+-----------+�������������� +-----------+
|�������������������������� |
... -------+------+------+-------------+------+------+------- ...
|������������ |������������ |������������ |
+-------+���� +-------+���� +-------+���� +-------+
| Agent |���� | Agent |���� | Agent |���� | Agent |
+-------+���� +-------+���� +-------+���� +-------+
L’analogie, utilisée par l’un des outils, entre les Agents et des feuilles permet bien d’imaginer l’organisation arborescente du réseau en assimilant les Serveurs à des branches.
Le client, utilisé par l’attaquant, contrôle un ou plusieurs Serveurs, lesquels communiquent avec les Agents chargés de la mise en oeuvre du déni de service. Pour éviter que les Agents et les Serveurs ne puissent être utilisés par autrui (administrateur légitime de l’hôte, autres pirates) toutes les commandes vers ces programmes nécessitent des mots de passe ou des informations supplémentaires.
5.2 Détails sur quelques outils
Les divers programmes étant disponibles sous forme de code source, toutes les valeurs citées ci-dessous ne sont pas garanties : un pirate à la petite semaine compilera vraisemblablement les sources en l’état, mais il est à la portée de tout programmeur d’analyser le code (un peu commenté) et de modifier en conséquence les numéros de ports, les chaînes de commande, les mots de passe, …
Pour analyse, les sources sont disponibles sur le serveur de packet storm [#!PacketStorm!#].
5.3 trinoo
Les connexions entre les divers Agents sont résumées dans le schéma ci-dessous :
������� 27665/tcp����������� 27444/udp Client -----------> Serveur -----------> Agent ���������������������������<----------- ���������������������������� 31335/udp
En l’absence de rootkit, netstat donne :
- serveur
-
Protocole Adresse locale tcp 0.0.0.0:27665 udp 0.0.0.0:31335 - Agent
-
Protocole Adresse locale tcp 0.0.0.0:27444
Les connexions sont réalisées en clair, par conséquent toutes les chaînes ci-dessous peuvent être identifiées par un renifleur de paquets.
5.3.1 Installation
Lorsqu’un Serveur est lancé sur une machine compromise, il réclame un premier mot de passe (gOrave, par défaut) et passe alors en tâche de fond. Le Serveur crée un fichier (appelé ... par défaut) pour stocker le nom des agents que se seront fait connaître (il peut exister un second fichier ...-b qui est une copie de secours créée après certaines commandes).
L’Agent, lorsqu’il démarre, cherche à contacter un certain nombre de serveurs (inscrits en dur dans le binaire) sur le port UDP 31335 en envoyant la chaîne *HELLO*. Si un Serveur est à l’écoute, il répond sur le port UDP 27444 de l’Agent par la commande png 144adsl (la commande png demande un accusé de réception à l’Agent et 144adsl est le mot de passe par défaut entre le Serveur et l’Agent). L’Agent répond alors sur le même port que précédemment par la chaîne PONG. Cela termine la phase d’identification et son adresse est stockée chiffrée par le Serveur dans le fichier ... à l’aide de l’algorithme symétrique BlowFish.
5.3.2 Attaque
Le Client se connecte sur le port TCP 27665 d’un Serveur, s’authentifie avec un mot de passe (betaalmostdone par défaut) et peut alors envoyer un certain nombre de commandes d’administration (liste des Agents identifiés et vérification qu’ils sont actifs, arrêt des Agents, …). Il peut demander un déni de service sur une ou plusieurs adresses IP. Le Serveur contacte alors les Agents qui ouvrent un socket sur un port non privilégié et lancent une multitude de paquets UDP vers des ports aléatoires des cibles.
À priori, les Agents ne modifient pas l’adresse source des paquets, par conséquent les cibles seraient en mesure d’identifier les Agents.
Pour des informations plus complètes, voir trinoo.analysis de D. Dittrich (cite [#!Dittrich!#]).
5.4 TFN
������� tout shell���������� echo_reply/icmp
Client -----------> Serveur ----------------> Agent
�������� distant����������� <---------------- ������
���������������������� echo_reply/icmp
En l’absence de rootkit, netstat donne :
- Serveur
-
Protocole Adresse locale Commentaire raw 0.0.0.0:1 plus une éventuelle connexion telnet, SSH, … - Agent
-
Protocole Adresse locale raw 0.0.0.0:1
Tout système possède, en standart, ce type de socket ouverte : ce n’est donc pas une caractéristique d’un système compromis.
5.4.1 Installation
Contrairement à trinoo la procédure d’installation est très simple :
- les Agents n’ont pas connaissance des Serveurs, donc pas d’étape d’identification ;
- les Serveurs ne gèrent pas non plus de fichier particulier pour stocker la liste des Agents, cette dernière leur étant fournie par le nom d’un fichier passé en argument.
5.4.2 Attaque
Le Serveur reçoit ses ordres sous forme de ligne de commande : le Client doit donc se connecter sur l’hôte avec un shell distant (en clair avec telnet, chiffré avec SSH, …). Le Serveur ne nécessite pas de mots de passe, mais il faut systématiquement fournir un fichier des Agents dans la commande. Les ordres qui peuvent être transmis aux Agents sont :
- choix du masque pour falsifier les adresses sources (aléatoire, modification d’un, de deux ou de trois des octets de plus faible(s) poids de l’adresse de l’Agent) ;
- changement de la taille des paquets d’attaque ;
- attaques par saturation de requêtes UDP, TCP, ICMP sur plusieurs adresses ou smurf sur une seule (en précisant un ou des réseaux amplificateur) ;
- ouverture d’un shell distant sur un port donné par les hôtes des Agents.
La communication entre un Serveur et des Agents se fait en utilisant des messages ICMP echo_reply (cf. RFC 792) où le champ identifiant (16 bits) contient la commande transmise et le segment données les arguments ou messages. Les Agents ne produisent qu’un seul type de commande, un accusé de réception (0x007B ou 123 en décimal par défaut).
Chaque Agent en phase d’attaque peut créer jusqu’à 50 processus fils pour attaquer autant de cibles depuis l’hôte.
Pour des informations plus complètes, voir tfn.analysis de D. Dittrich ([#!Dittrich!#]).
5.5 Stacheldraht(fil de fer barbelé en allemand)
C’est un outil partiellement basé sur TFN (dont il reprend le code de l’Agent) mais qui a comme caractéristique de chiffrer toutes ses communications TCP. De plus, il comporte des instructions de compilation pour Linux et Solaris.
Version intiale (analysée par D. Dittrich) :
������� 16660/tcp���������� -----------------------------> Client -----------> Serveur� 65000/tcp et echo_reply/icmp� Agent ��������������������������� <-----------------------------
Version 4 actuellement disponible :
������� 61111/tcp����������� 65512/tcp et echo_reply/icmp
ou 65512/tcp�������� ou 65513/tcp
Client -----------> Serveur ----------------------------->� Agent
��������������������������� <-----------------------------
���������������������������������� echo_reply/icmp
En l’absence de rootkit, netstat donne :
- Serveur
-
Protocole Adresse locale Commentaire tcp 0.0.0.0:x où x=16660, 61111 ou 65512 raw 0.0.0.0:1 - Agent
-
Protocole Adresse locale Commentaire tcp 0.0.0.0:x où x=65000, 65512 ou 65513 raw 0.0.0.0:1
5.5.1 Installation
On trouve une phase d’installation semblable à trinoo : les Agents possèdent un fichier avec une liste de Serveurs (.ms par défaut) chiffré avec BlowFish ou bien se réfèrent à 2 Serveurs par défaut codés dans le binaire. L’identification mutuelle se fait par l’envoi d’un message ICMP echo_reply en clair avec comme identifiant 666 en décimal et skillz dans le champ de données. Tout Serveur présent répond par un echo_reply avec un identifiant 667 et ficken en données. L’Agent procède alors à un test pour savoir si il peut émettre des adresses sources complètement aléatoire en envoyant vers un Serveur un paquet ICMP echo_reply d’adresse source 3.3.3.3 avec son adresse réelle dans les données (identifiant 666). Si le message arrive au Serveur il répond via echo_reply avec un identifiant à 1000 et spoofworks (l'usurpation fonctionne !) dans les données. En cas de succès l’Agent fabriquera des adresses sources quelconques, sinon il se limitera à modifier l’octet de poids le plus faible (ce qui permet au moins à la cible d’identifier le réseau ou sous-réseau émetteur).
Le Serveur stocke les Agents identifiés dans un fichier .bc chiffré avec BlowFish.
5.5.2 Attaque
Il faut utiliser un client dédié qui chiffre (à l’aide de BlowFish) tout le trafic TCP avec le Serveur. Après authentification à l’aide d’un mot de passe, les commandes suivantes peuvent être transmises aux Agents via echo_reply/icmp (la commande est un code dans l’identifiant) :
- gestion de la liste de Serveurs des Agents (ajout, retrait) ;
- liste des Agents présents et morts après un test de la connexion TCP ;
- changement de la taille, des ports cibles, pour les paquets d’attaque ;
- attaques par saturation de requêtes UDP, TCP, ICMP sur plusieurs adresses ;
- ouverture d’un shell distant sur un port donné par les hôtes des Agents ;
- mise à jour de chaque Agent en utilisant le programme rcp sur la machine hôte.
Chaque Agent a la possibilité de créer un certain nombre de processus fils (1 par défaut et 15 maximum) pour attaquer séquentiellement l’ensemble des cibles.
Pour des informations plus complètes, voir stacheldraht.analysis de D. Dittrich (cf. [#!Dittrich!#]).
5.6 TFN2K
Il s’agit d’une évolution de TFN, ayant pour but de diversifier les attaques réalisées et d’améliorer la furtivité suite aux vulnérabilités et signatures (binaires, trafic réseau) publiées après l’analyse de TFN. Par ailleurs le code comporte des directives pour la compilation sous Linux, Solaris et Windows.
������� tout shell���������� echo_reply/icmp ou tcp ou udp Client -----------> Serveur -------------------------------> Agent �������� distant����������� <------------------------------- ���������������������������� echo_reply/icmp ou tcp ou udp
En l’absence de rootkit, netstat donne :
- Serveur
-
Protocole Adresse locale Commentaire raw 0.0.0.0:x où x=1(icmp), 6(tcp) ou 17(udp) plus une éventuelle connexion telnet, SSH, … - Agent
-
Protocole Adresse locale raw 0.0.0.0:1 raw 0.0.0.0:6 raw 0.0.0.0:17
5.6.1 Installation
Semblable à TFN.
5.6.2 Attaque
Le Serveur reçoit ses ordres sous forme de ligne de commande : le Client doit donc se connecter sur l’hôte avec un shell distant (en clair avec telnet, chiffré avec SSH, …). Le Serveur nécessite un éventuel de mot de passe, mais il faut fournir un fichier des Agents où l’adresse de l’un d’eux dans la commande. Les ordres qui peuvent être transmis aux Agents sont :
- protocole de communication avec les Agents TCP, UDP, ICMP ou aléatoire par défaut ;
- choix du masque pour falsifier les adresses sources (aléatoire, modification d’un, de deux ou de trois des octets de plus faible(s) poids de l’adresse de l’Agent) ;
- changement de la taille des paquets d’attaque ;
- attaques par saturation de requêtes UDP, TCP, ICMP, smurf (en précisant un ou des réseaux amplificateur) ou un mélange des trois premiers ;
- attaque dite TARGA3 fabricant des paquets IP avec des protocoles, des valeurs de fragmentation et des drapeaux normaux et fantaisistes auxquels certaines (?) piles TCP/IP sont sensibles avec toutes sortes de conséquences néfastes pour la cible ;
- réalisation d’une commande shell quelconque par les Agents. Cela offre un champ immense de possibilités d’agression : envois massifs de mails, mise à jour des agents, récupération de tout fichier (dont mots de passe) sur les hôtes, activation des scripts d’un serveur HTTP cible, … (dans ces cas, l’adresse source ne peut pas être falsifiée sans outil complémentaire) ;
- ouverture d’un shell distant sur un port donné par les hôtes des Agents.
La communication un Serveur et des Agents se fait en utilisant le champ de données d’un paquet TCP, UDP ou ICMP (choix aléatoire par défaut) en chiffrant la commande avec l’algorithme symétrique CAST-256. L’Agent est à l’écoute des trois protocoles et, en déchiffrant le champ de données, détermine si le paquet lui est destiné.
Chaque Agent en phase d’attaque peut créer jusqu’à 50 processus fils pour attaquer autant de cibles depuis l’hôte.
Pour d’autres informations, voir l’analyse d’Axent Security Team (cf. [#!AXENT!#]).
No References!
