Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2000-INF-001
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 21 février
2000 No CERTA-2000-INF-001 |
Affaire suivie par :
CERTA
Objet : Le déni de service
distribué
| 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-2000-INF-001 |
Une gestion de version détaillée se trouve à la fin de ce document.
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.
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.
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 ».
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.
Les systèmes suivants sont connus comme pouvant être des machines servant d'intermédiaires dans les attaques de déni de service :
http://asu.info.apple.com/swupdates.nsf/artnum/n11560
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 :
A l'instar des outils de détection de virus :
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.
|
Une étude régulière de la configuration de chaque système peut aider à trouver les logiciels DDoS.
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.
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.
Par rapport aux outils traditionnels d'attaque, les outils distribués sont caractérisés par :
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.
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 [11].
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 :
| Protocole | Adresse locale |
| tcp | 0.0.0.0:27665 |
| udp | 0.0.0.0:31335 |
| 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.
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.
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 [5]).
tout shell echo_reply/icmp
Client -----------> Serveur ----------------> Agent
distant <----------------
echo_reply/icmp
En l'absence de rootkit, netstat donne :
| Protocole | Adresse locale | Commentaire |
| raw | 0.0.0.0:1 | plus une éventuelle connexion telnet, SSH, ... |
| 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.
Contrairement à trinoo la procédure d'installation est très simple :
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 :
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 ([5]).
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 :
| Protocole | Adresse locale | Commentaire |
| tcp | 0.0.0.0:x | où x=16660, 61111 ou 65512 |
| raw | 0.0.0.0:1 |
| Protocole | Adresse locale | Commentaire |
| tcp | 0.0.0.0:x | où x=65000, 65512 ou 65513 |
| raw | 0.0.0.0:1 |
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.
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) :
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. [5]).
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 :
| 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, ... |
| Protocole | Adresse locale |
| raw | 0.0.0.0:1 |
| raw | 0.0.0.0:6 |
| raw | 0.0.0.0:17 |
Semblable à TFN.
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 :
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. [3]).
http://www.cert.org/advisories/CA-2000-01.html;
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html;
http://www.cert.org/incident_notes/IN-99-07.html
http://www.cert.org/reports/dsit_workshop.pdf
http://www.securityportal.com/direct.cgi?/research/ddosfaq.html.
http://www2.axent.com/swat/NewsTFN2k_Analysis.htm.
http://www.cisco.com/warp/public/707/newsflash.html.
http://staff.washington.edu/dittrich/misc/ddos/.
http://www.fbi.gov/nipc/trinoo.htm.
http://www.sans.org/giac.htm.
http://mixter.void.ru.
http://www.nessus.org.
http://www.insecure.org.
http://packetstorm.securify.com/distributed/.
http://www.tripwire.com.