-*- Indented-Text -*- ------------------------------------------------------------------------ LES RISQUES LIÉS À NESSUS ------------------------------------------------------------------------ 0. Copyright Ce document a été rédigé par Michel Arboi Je permets à quiconque de le reproduire, transmettre, imprimer, calligraphier à la plume d'oie sur parchemin, graver dans le marbre, transférer sur un tee shirt, etc. pourvu qu'il ne soit pas modifié -- et a fortiori, que ce copyright soit toujours présent. 1. Pourquoi ce document ? On peut avoir de désagréables expériences en lançant un test Nessus contre une machine fragile ou en laissant un tel outil à la portée de n'importe qui. Certains n'ont pas vraiment compris le mode de fonctionnement de Nessus, ni même les risques liés à n'importe quel test dit "de sécurité". 2. Considérations légales N'étant pas juriste, je ne m'étendrai pas sur ce sujet. Nessus est distribué selon la GPL. Mélanie Clément-Fontaine a étudié cette licence http://crao.net/gpl/ mais à ma connaissance, il n'existe aucune jurisprudence. Nessus est distribué SANS AUCUNE GARANTIE, tout comme n'importe quel logiciel d'ailleurs. Ne venez pas vous plaindre si vous cassez une machine en production ; de toute façon, vous n'êtes pas plus couverts avec un scanner commercial. Mais au moins, nous vous aurons prévenus des dangers potentiels. 3. Comment fonctionne Nessus 3.1. Séquence des opérations a) Nessus détermine les ports ouverts - en appelant le scanner externe nmap, - en appelant snmpwalk (contre une machine très mal configurée), - en utilisant un plugin interne, calqué sur un des modes de fonctionnement de nmap, - ou en utilisant un fichier externe, vu comme un résultat de nmap, obtenu par un moyen quelconque, par exemple en convertissant la sortie de la commande netstat. b) Ensuite le plugin "find_service" tente d'identifier ce qui tourne derrière chaque port - tout d'abord en tentant des connexions SSL (TLSv1, SSLv3, SSLv2), puis standard, - ensuite en envoyant diverses séquences au service et en regardant les réponses find_service stocke ses découvertes sous forme de "clés" dans la "base de connaissance" (KB). c) Sur chacun des ports ouverts, Nessus tente alors diverses attaques. Par exemple, si un script vise les serveurs web, il sera lancé contre tous les ports où tourne un serveur HTTP _ou_ HTTPS. 3.2. Types et fonctionnements de plugins Les plugins de Nessus sont classés par famille. Ceci permet de les regrouper dans l'interface graphique, mais n'a aucune influence sur le fonctionnement du scanner. Il existe une famille "déni de service", mais elle ne regroupe pas tous les scripts dangereux, seuls ceux dont le but premier est de tuer le système. Chaque plugin a une "catégorie" : - ACT_INIT Le script sert simplement à configurer des options et ne fait aucun test. - ACT_SCANNER Le script est un scanner de ports ou apparenté (e.g. ping). - ACT_SETTINGS Même fonction qu'ACT_INIT, mais passe après les scanners, quand on est sur que la machine répond. - ACT_GATHER_INFO Le script récupère des informations sur le système, par exemple identifie des services ou vérifie la présence d'un logiciel particulier. - ACT_ATTACK Le script tente de percer certaines défenses, en théorie sans effet pervers contre la disponibilité du système. - ACT_MIXED_ATTACK Le script est susceptible d'avoir des effets secondaires désastreux, bien que ce ne soit pas son but. - ACT_DESTRUCTIVE_ATTACK Le script tente de perturber un service ou détruire des données. - ACT_DENIAL Le script tente un déni de service contre un logiciel particulier. - ACT_KILL_HOST Le script tente un déni de service contre la machine / le système d'exploitation. - ACT_END le script se contente de compiler des information une fois que tout le reste est passé. La frontière entre toutes ces catégorie est floue, et il est impossible de prédire a priori si un script qui vise un logiciel donné n'aura pas des effets dangereux contre un autre. Nessus exécute en premier les scripts ACT_INIT, puis les plugins ACT_SCANNER, puis ACT_SETTINGS, ACT_GATHER_INFO, etc. Notes: - ACT_INIT, ACT_END et ACT_KILL_HOST ont été introduits en version 1.3.0 Avant (1.2.6), les éventuels scripts ACT_INIT étaient déclarés comme ACT_SETTINGS et ACT_KILL_HOST était fusionné avec ACT_DENIAL - avant la version 1.2.6, ACT_SETTINGS passait en tête, mais ceci faisait perdre du temps lorsqu'on scannait une plage d'adresses où peu de machines était vivantes. En mettant ACT_SCANNER en premier, on filtre avec ping.nasl Enfin, chaque script déclare des "dépendances" - en terme de scripts qui ont dû tourner avant. Par exemple, la plupart des scripts dépendent de "find_service". - en terme de ports /services ouverts Par exemple, les scripts qui testent des vulnérabilités HTTP déclareront dépendre du port 80 et de la clé "Services/www". Par principe, Nessus ne considère rien comme acquis. Contrairement à certains scanners de sécurité qui basent leurs vérifications sur les bannières présentées, Nessus attaque réellement les services, sauf dans quelques rares cas mentionnés dans le rapport, ou bien si l'option "safe checks" est active (voir ci-dessous). En conséquence : - Nessus est capable de détecter si une faille _censée_ être corrigée dans la version N+1 d'un logiciel est toujours là. - Nessus peut découvrir qu'une faille dirigée contre le produit X fonctionne aussi contre le produit Y. - Nessus a la mauvaise habitude de démolir les services codés "avec les pieds" sans aucune pitié. 3.3. Sélection des scripts L'interface graphique permet de - tout sélectionner en un clic, - sélectionner "tout sauf les plugins dangereux". Ce choix élimine les plugins de catégorie ACT_DENIAL, ACT_KILL_HOST ou ACT_DESTRUCTIVE_ATTACK. Il fait double emploi avec l'option "safe checks" et devrait disparaître à terme. - sélectionner ou non chaque plugin individuellement. - sélectionner une famille entière. Gardez à l'esprit que les scripts dangereux ne sont pas tous dans la famille "déni de service" ! 3.4. Options importantes Trois options dans l'interface influencent la résolution des dépendances : - Enable dependencies at run time - Optimize the test - Consider unscanned ports as closed Et une quatrième modifie le comportement des scripts agressifs : - Safe checks 3.4.1. Enable dependencies at run time Par défaut, Nessus ne lance pas un script si ceux dont il dépend n'ont pas été activés. Cette option résout automatiquement les dépendances nécessaires. 3.4.2. Optimize the test Par défaut, Nessus lance même les tests qui n'ont aucune chance de réussir, parce que le service n'a pas été identifié (il attaquera le port par défaut). Cette option accélère le test, au risque de rater quelques vulnérabilités. 3.4.3. Consider unscanned ports as closed Par défaut, Nessus considère les ports non scannés comme "ouverts". Cette option inverse le comportement et accélère le test. Elle n'a d'effet que combinée avec "optimize the test". 3.4.4. Safe checks Cette option désactive les tests dangereux susceptibles de tuer le système ou un service. Nessus s'appuie si possible sur les numéros de version renvoyés par les bannières, par exemple. Si aucun indice n'est disponible, le test est tout simplement abandonné. Cette option est moins inoffensive qu'elle paraît : - Elle peut donner un faux sentiment de sécurité. Qu'une faille ne soit pas mentionnée dans le rapport ne signifie pas qu'elle soit absente du système. - Si le script est mal écrit et ne vérifie pas la valeur de l'option avec la fonction safe_checks(), l'attaque sera quand même lancé. A priori, les scripts livrés avec Nessus sont sûrs, mais un script "non officiel" ou expérimental pourrait être dangereux. NB : les scripts ACT_DENIAL, ACT_KILL_HOST et ACT_DESTRUCTIVE_ATTACK ne sont jamais lancés quand cette option est activée. 4. Comment un test de sécurité peut tuer votre système 4.1. Politique Avant d'accabler Nessus de sordides qualificatifs, sachez que toucher une machine sensible en production est suicidaire. Les consultants sécurité sont rarement appréciés : ils sont vus soit comme des pirates, soit comme des cyberflics. Si la machine part en vrille au moment où vous commencez votre test pour une raison externe, on sera trop heureux de vous rendre responsable des dommages causés. Que vous soyez convaincu de n'avoir rien fait de mal est une chose, que vous sachiez convaincre le juge qui doit évaluer les responsabilités et le montant du préjudice subi en est une autre. Les arguments contractuels simplistes ne tiennent pas devant un tribunal, en France du moins. N'oubliez pas que le droit n'est pas une science exacte (en fait, ce n'est pas une science du tout :-) 4.2. Les dangers du scan de ports - En TCP, le scanner ouvre une connexion puis la referme immédiatement sans envoyer de données. Certains logiciels meurent ou partent en boucle s'ils n'arrivent pas à lire de données. Contrairement à ce que certains pourraient penser, les scans furtifs "nul scan" ou "Christmas tree" présentent moins de risques car ils ne remontent pas jusqu'aux logiciels applicatifs potentiellement bugués. Ils ne marchent pas contre tous les systèmes d'exploitation, hélas. - En UDP, il envoie un paquet sans données. Ceci est suffisant pour tuer certaines piles IP défectueuses ou un logiciel mal codé. - dans quelques cas rares maintenant, les scans furtifs ou l'identification du système par "fingerprinting" peuvent tuer la pile IP. On rencontre encore des logiciels embarqués vulnérables à ce genre de déni de service. - snmpwalk peut lui aussi être dangereux ! On peut récupérer la liste des ports ouverts par la commande netstat puis la convertir avec la commande netstat2nmap.pl en un pseudo fichier nmap, lisible par Nessus. Ainsi, on n'a pas à lancer le scanner. Toutefois, l'intérêt de cette opération était plutôt d'accélérer le test que d'en limiter les risques. 4.3. Entreprise de démolition Nessus & Cie Certains scripts génériques sont particulièrement méchants : - Débordements mémoire contre divers champs / requêtes des protocoles HTTP, FTP, POP3... - Requêtes mal formées (HTTP, FTP...) - Tests par saturation, inondant un service inconnu de myriades d'octets. Par ailleurs, outre les effets secondaires du scanner de port, certains logiciels n'apprécient pas l'interrogatoire que leur fait subir find_service, à commencer par les multiples tentatives de connexion SSL. check_ports, un plugin qui teste d'éventuels dénis de service provoqués par un scanner de ports ou find_service, fait l'équivalent d'un "nmap -sT" sur les ports supposés ouverts. Avec les risques (faibles) que cela comporte... Même un simple plugin de type ACT_GATHER_INFO peut tuer un service mal conçu. Le risque zéro n'existe pas ! Notez qu'il existe un test qui pourrait réellement tenter d'effacer des données : http_methods.nasl. Toutefois, la partie de code dangereuse est désactivée en mode "safe checks". 5. Limitation des risques Vous tenez à tester votre application sensible et en cas de problème, vous ne vous en prendrez qu'à vous même. En clair, vous voulez affirmer haut et fort votre condition d'homme libre en vous tirant dans le pied. Vous aimeriez bien que ça ne fasse pas trop mal... [Dans la suite, la machine cible s'appelle guinea-pig] 5.1. Supprimez le port scan - Connectez-vous sur guinea-pig, lancez "netstat -a -n --inet" ou tout autre commande nécessaire sur votre système pour récupérer les ports IP ouverts (--inet) sous forme numérique (-n). - Écrivez le résultat dans un fichier nommé "guinea-pig" (il est important que ce fichier porte le nom de la machine "scannée") - Convertissez-le en fichier nmap par : netstat2nmap guinea-pig > gp.nmap - ne sélectionnez _que_ le scanner "nmap" et jetez lui gp.nmap en pâture. La plage de ports "scannée" devrait être 1-65535 5.2. Limez les dents de Nessus - Activez l'option "safe checks" - Activez "optimize the test". - Désactivez "enable dependencies at run time". - Supprimez les plugins que vous pensez inutiles ou dangereux. - Si aucun service ne s'appuie sur SSL, désactivez "test SSL services" (une des "préférences" du plugin find_service) - désactivez check_ports.nasl 5.3. Risques résiduels - find_service est susceptible de faire plus de dégats que le scanner de ports, même sans les essais de connexions SSL. - des plugins ACT_GATHER_INFO peuvent avoir le même effet, mais "optimize the test" réduit les risques. 9. Nessus entre de mauvaises mains Nessus est un redoutable outil de test, capable aussi bien d'indiquer aux "chapeaux blancs" les correctifs qu'ils doivent appliquer pour durcir leur système ou aux "chapeaux noirs" les "exploits" qu'ils doivent utiliser pour percer les défenses de la machine. 9.1. Une arme en vente libre ? Je n'ai pas envie de relancer le troll^W débat "pour ou contre le full disclosure". Comme beaucoup d'outils, ce n'est pas Nessus lui même mais son utilisation qui peut être bonne ou mauvaise. Nessus est destiné aux "chapeaux blancs". Ses principes de conception ne facilitent pas la vie des pirates : il est terriblement bruyant. Les pirates cherchant généralement à être discrets, c'est raté. Il est possible de torturer Nessus pour le faire passer par l'un des nombreux proxys ouverts qui traînent sur Internet. Pour des raisons que vous comprendrez, j'espère, je n'ai pas envie de documenter la procédure :-] Quelques traces (petit extrait) : Dec 15 16:43:32 casserole login(pam_unix)[5888]: authentication failure; logname= uid=0 euid=0 tty=pts/17 ruser= rhost=localhost user=root Dec 15 16:43:32 casserole login(pam_unix)[5886]: check pass; user unknown Dec 15 16:43:32 casserole login(pam_unix)[5886]: authentication failure; logname= uid=0 euid=0 tty=pts/16 ruser= rhost=localhost Dec 15 16:43:34 casserole login[5880]: FAILED LOGIN 1 FROM localhost FOR backdoor, Authentication failure Dec 15 16:43:56 casserole fam[1354]: fd 109 message length 1312236900 bytes exceeds max of 4135. Dec 15 16:44:11 casserole SERVER[5930]: Dispatch_input: bad request line '< NTP/1.0 >^M' 127.0.0.1 - - [15/Dec/2001:16:44:39 +0100] "GET http://www.nessus.org HTTP/1.0" 200 2890 "-" "-" 127.0.0.1 - - [15/Dec/2001:17:25:44 +0100] ".`" 501 - "-" "-" 127.0.0.1 - - [15/Dec/2001:17:25:45 +0100] "GET /cgi-bin/nessus_is_probing_this_host_2033195663 HTTP/1.1" 404 335 "-" "Mozilla/4.75 [en] (X11, U; Nessus)" 127.0.0.1 - - [15/Dec/2001:17:29:58 +0100] "are you dead ?" 400 339 "-" "-" 9.2. Fonctions anti NIDS La version 1.1.13 a introduit des fonctions "d'évasion", au niveau TCP et HTTP, qui s'appuient sur divers travaux disponibles publiquement. http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html http://www.securityfocus.com/data/library/ids.ps http://rr.sans.org/intrusion/anti-ids.php Le but de ces fonctions n'est pas de permettre aux "black hats" d'attaquer plus facilement les systèmes ouverts sur Internet, mais aux "white hats" de tester les mesures de protection mises en place. L'outil freeware Snort n'est trompé par aucune de ces options, et en fait Nessus est perçu comme plus bruyant quand elles sont actives. 9.3. Contrôle d'accès à Nessus Nettement plus grave, un pirate pourrait prendre le contrôle d'un serveur Nessus dirigé contre vos machines ou celles de vos clients. Nul n'est à l'abri d'un bug, mais certaines précautions devraient ramener le risque à un niveau acceptable : - Si le client et le serveur tournent sur la même machine, configurez Nessus pour utiliser les sockets Unix. Vérifiez que le port 1241 est fermé. - Configurez Nessus avec les TCP wrappers et limitez l'accès aux rares postes qui en ont besoin, par exemple localhost. - Activez l'authentification par certificats client X.509. Générez vos propres certificats, n'utilisez surtout pas ceux de la "kabale Nessus" ! Le mieux est de protéger vos clés privées (serveur et client) par un mot de passe solide, ce que le script nessus-mkcert ne fait pas. Vous devrez mettre en place votre propre "usine à certificats". - Éteignez la machine qui héberge le serveur Nessus quand elle n'est pas utilisée. Note: actuellement, l'authentification par certificats est incompatible avec les sockets Unix.