Par Robert Keyes pour Razor
Source : http://razor.bindview.com/publish/advisories/adv_NAPTHA.html
Translation by eberkut - http://www.chez.com/keep

Vue d'ensemble

Une nouvelle catégorie de vulnérabilités DoS a été découverte, et Naphta est le nom générique la désignant. Les vulnérabilités proviennent de faiblesses dans la manière dont la pile TCP/IP et les applications réseau manipulent l'état d'une connexion TCP.

Systèmes Affectés

Une forte proportion des applications et systèmes réseau

Notes

Compaq - Tru64 UNIX V4.0F

Deux services ont été testés, portmapper (port TCP 111) et finger (port TCP 79). Ces services ont été choisis parce que le finger fonctionne de l'inetd et le portmapper fonctionne sans lui.

Le kernel de Tru64 UNIX semble être quelque peu robuste contre des attaques de Naptha. L'envoi de 20000 paquets au port TCP 111 n'a causé aucune dégradation évidente d'exécution sur l'hôte de Tru64 UNIX (sauf que d'autres tentatives de requêtes sur le portmapper n'ont pas aboutie). La commande de netstat a montré une valeur équilibrée de 4100 connexions ÉTABLIES.

Cependant, envoyer quelques 100 paquets au TCP 79 a eu comme conséquence la création de trop de processus du démon fingerd pour que le système continue l'exécution normale. La tentative de commencer un nouveau processus d'un login shell a eu comme conséquence l'erreur "no more process". Il est possible que l'attaque du démon fingerd aurait été moins pertinente avec une configuration différente d'inetd, ou avec différents paramètres du kernel.

FreeBSD - FreeBSD 4.0-REL

En testant FreeBSD, quelques démons/ports spécifiques ont été visés. Pour certains, la stabilité du système dans l'ensemble peut être affectée. Les démons visés lors de ce test ne sont pas nécessairement fautifs pour les problèmes encourus.

SSH
Est devenu inutilisable après 495 connexions au port ssh. Chaque connexion a commencé une instance du démon qui a rapidement épuisé les traitements disponibles de fichier ; le système signale "too many open files in the system". Après approximativement 30 minutes les connexions commencent à se terminer et le système redevient utilisable.

NFS
Stoppe le fonctionnement après 964 paquets au port de NFS. Tandis que le reste du système ne semblait pas affecté, les connexions ne se sont pas terminée.

BIND
A pris 961 connexions de TCP avant que le kernel signale "file table is full", et que le service TCP tombe en panne. UDP DNS a semblé inchangé. Ces connexions requiert un long temps d'attente avant de se terminer, au moins une heure.

Note : Ces services/ports peuvent être pareillement affectés sur d'autres variantes de Linux et d'Unix. General Linux - Linux 2.0 kernel-based systems TELNET
Le démon telnetd est mort après 500 paquets dans l'état ÉTABLI. Le démon telnetd n'a jamais récupéré, et ainsi beaucoup de ressources ont été épuisées, comme la mémoire, à tel point que le système a dû être relancé pour récupérer.

RPC
Le démon RPC a arrêté de répondre après 442 paquets dans l'état ÉTABLI. Comme l'attaque telnetd, on a compromis de la mémoire et d'autres ressources et le système a dû être relancé pour récupérer. Hewlett-Packard - HP-UX 11.00 Deux services ont été testés, portmapper et telnet. Ces services ont été choisis parce que le telnet fonctionne avec inetd et le portmapper fonctionne sans lui.

TELNET
HP-UX semble avoir une certaine protection. Il cesse de répondre aux paquets de Naptha après plusieurs centaines de la même adresses IP. Cependant, jusqu'à ce qu'il soit possible de faire répondre le telnetd avec "Telnet device drivers missing: No such device". Il récupère tout de même assez vite.

PORTMAPPER
Après plusieurs centaines de sessions de Naptha TCP, une session de telnet au port 111 sera immédiatement déconnectée. Cet état cassé dure beaucoup plus longtemps que le problème de telnet. Microsoft - Windows 95,98,98SE Laisser un grand nombre de connexions en FIN-WAIT-1 cause NetBIOS et les services WWW sur Windows 95, 98, et 98SE de Microsoft à échouer et à ne pas relancer. Microsoft - Windows NT 4.0 SP6a Exploiter l'état ÉTABLI sur le port 139 (netbios-ssn), cause la mort du service après 1010 paquets. Le port 135 (loc-srv) est mort après 7929 paquets. A noter que si le port 139 avait été précédemment détruit par Naptha, le port 135 serai mort après 2 paquets. Si l'attaque Naptha faisait une pause, le port 135 récupérerait mais serait immédiatement indisponible si l'attaque de Naptha était reprise. Quand le port 135 est mort, l'utilisation de l'unité de traitement arithmétique serait utilisée 100% et demeurerait dans cet état jusqu' à une réinitialisation.

Laisser un grand nombre de connexions en FIN-WAIT-1 cause NetBIOS et les services WWW sur Windows NT 4.0 de Microsoft à échouer et à ne pas relancer.

Novell - Netware 5 SP1 Verrouillé après 3000 connexions ouvertes sur le port 524, utilisation à 100% des 64 Mo de RAM et du CPU. Le serveur n'avait toujours pas terminé les connexions ni récupéré de mémoire après 12 heures laissées en veille. Red Hat - Red Hat Linux 6.1 Kernel 2.2.12 SSH
En utilisant l'état ÉTABLI, le sshd est devenu inutilisable après 519 paquets. L'utilisation de l'unité de traitement arithmétique a augmentée, rendant l'activité sur le système lente. Les processus démon engendrés ont empêcher de récupérer, bien que par la suite toutes les connexions en état ÉTABLI se sont terminées après environ 2 heures.

RPC
En utilisant l'état ÉTABLI, le démon RPC a cessé de répondre aux requêtes légitimes au bout d'environ 200 paquets, et est devenu inutilisable après 994 paquets. Le démon a dû être stoppé et relancé pour récupérer.

SRP Telnet daemon
Après 92 paquets, le démon telnet SRP-enabled a été surchargé. La reprise a exigé une réinitialisation pour effacer les processus et les connexions ÉTABLIE, qui ont eu des problèmes à se terminer toutes seules. SGI - IRIX 6.5.7m Deux services ont été testé, portmapper (port TCP 111) et sgi-dgl (port TCP 5232. Ces services ont été choisi parce que sgi-dgl fontionne avec inetd et portmapper fonctionne sans lui.

Le kernel IRIX semble résister convenablement aux attaques Naptha. L'envoi de 20000 paquets au port TCP 111 n'a causé aucune dégradation évidente d'exécution sur l'hôte Irix (sauf que d'autres tentatives de requêtes sur portmapper n'ont pas aboutie). La commande netstat a montré une valeur équilibrée de 195 connexions ÉTABLIES.

Cependant, envoyer quelques 100 paquets au TCP 5232 a eu comme conséquence la création de trop de processus du démon dgl pour que le système continue l'exécution normale. La tentative de commencer un nouveau processus d'un login shell a eu comme conséquence l'erreur "no more process". Il est possible que l'attaque du démon dgl aurait été moins pertinente avec une configuration différente d'inetd, ou avec différents paramètres du kernel.

Slackware - Slackware Linux 4.0 TELNET
Après 224 paquets ÉTABLI, le service TCP est tombé en panne et aucun autre processus ne peut être lancer. Un rebootage sauvage est nécessaire pour récupérer (ctrl-alt-suppr ne fonctionne pas).

RPC
Après 448 paquets ÉTABLI, le service TCP est tombé en panne et aucun autre processus ne peut être lancer. Comme pour telnet, un rebootage sauvage est nécessaire pour récupérer.

Sun - Solaris 7, 8 Deux services ont été testé, portmapper et telnet. Ces services ont été choisi parce que telnet fonctionne avec inetd et portmapper fonctionne sans lui.

TELNET
Au bout d'environ 700 sessions TCP Naptha, une session telnet sera obtenue, suivie du message "can't grant slave pty" et enfin débranchée. Au bout de 1700 sessions TCP Naptha, une session de telnet sera reliée mais rien d'autre ne se produit. Ceci n'est pas confiné au port de telnet mais bien à tous les ports. Si l'attaque de Naptha est arrêtée, par la suite le telnet récupérera. La durée pendant laquelle il est cassé dépend de la vitesse et de la longueur de l'attaque Naptha ainsi que d'autres facteurs. Le temps d'arrêt typique était une heure.

PORTMAPPER
Au bout d'environ 300 sessions TCP Naptha, une session telnet sur le port 111 est immédiatement déconnectée (normalement, elle est déconnectée quand un utilisateur entre la clé d'entrée). Ce défaut n'affecte pas d'autres services. Le temps d'arrêt est variable mais dure en général 2 heures.

En créant un nombre assez grand de connexions TCP et en les laissant dans certains, les différentes applications ou le système d'exploitation lui-même peuvent être mis hors service. Des attaques exploitant les connexions de TCP de cette manière n'ont pas été mises en application parce qu'elles épuisent aussi bien les ressources de l'attaquant que celle de la cible. L'innovation apporté par l'attaque Naptha est qu'il est possible de créer facilement un DoS sur la cible avec peu de consommation de ressource de la part de l'attaquant.

DoS
Une attaque DoS est une action utile pour dégrader de manière significative la qualité et/ou la disponibilité des services d'un système.

DoS->RS
La Resource Starvation est un type d'attaque DoS. Ici nous avons besoin de définir la différence entre une attaque et une vulnérabilité notable. Avec des ressources réseau suffisantes à disposition de l'attaquant, n'importe quel système est vulnérable à DoS->RS.
Ce qui fait de DoS->RS une méthode notable est qu'elle consomme bien plus de ressources auprès de la victime que de l'attaquant. Une différence importante entre des niveaux de ressource indiquent une vulnérabilité dans le système de la victime. Cette vulnérabilité s'exploite sous forme d'exploit.

DoS->RS->TCP_STATE
Le kernel log chaque connexion TCP. Un grand nombre de connexions, indépendamment de l'activité, exigent plus de mémoire et de temps CPU. Il est théoriquement possible pour un utilisateur sur un machine avec un grand quantité de mémoire, une unité de traitement arithmétique rapide et un système d'exploitation correctement configuré de perturber un peu le système rien qu'en utilisant des programmes standard tels que Telnet, toutefois la quantité de ressources consommées sur le système attaquant est trop importante pour que ce ne soit pas considéré comme une vulnérabilité sérieuse.
Un programme d'attaque utilisant une API réseau tel que l'interface socket BSD est plus efficace et donc plus dangereux, mais n'est pas habituellement assez efficace pour exposer une vulnérabilité dangereuse sur le système de la victime.

Détails

Naptha est une démonstration d'une exploit efficace de DoS->RS->TCP_STATE. Il est efficace parce qu'il n'emploie pas une traditionnelle API réseau pour initier une connexion TCP. À la différence d'une vraie pile TCP/IP, il ne garde aucun enregistrement d'état de connexion. il répond à un paquet en ce basant basé sur les seul indications de ce paquet. Une fois en fonction, il produira des centaines ou milliers de connexion enregistré sur la victime, il consomme très peu de ressources à l'attaquant par rapport au niveau élevé de ressources requise à la cible. De cette façon, il peut exploiter les vulnérabilités d'un service particulier, ou la pile TCP/IP elle-même, sur le système de la victime.

Fonctionnement de Naphta

Bien qu'il y eut quelques travaux sur ce sujet, personne n'a édité ou a démontré un outil qui peut laisser des connexions dans n'importe lequel des divers états TCP sur la machine victime (ÉTABLIE et FIN-WAIT-1, etc...) ou une architecture à plusieurs éléments (permettant à un de cacher une partie de l'attaque sur différents centres serveurs).
Naptha tire en grande partie son efficacité du fait que l'attaque peut être faite d'une façon distribuée.

La première partie envoie une séquence de paquets SYN spoofés à tous les ports possibles à la victime. Selon les conditions du scénario d'attaque, des copies multiples de ce programme sur le même centre serveur pourraient être employées pour attaquer différents centres serveurs, ou les centres serveurs multiples pourraient attaquer une unique victime. Ceci ressemble à un SYN flood, mais il y a plus.

La 2ème partie fonctionne sur un réseau local où l'adresse IP serait forgée, si c'était un vrai hôte. Le programme s'assure d'abord que le routeur a une entrée pour cet hôte fantôme dans sa table ARP. Ensuite, il écoute en mode promiscous les paquets entre la victime et l'hôte fantôme. Le programme renvoie un paquet avec les flags et numéros de séquences appropriés. Précisément, il écoute les paquets SYN/ACK et renvoie un ACK. Il pourrait également placé le flag FIN et laisser la connexion en état FIN-WAIT-1. Pour garder la connexion plus longtemps, il peut détecter les paquets "réguliers" de données ou gardez les paquets "vivants" et envoyez un ACK en réponse. Des victimes multiples pourraient être visées par un exemple simple de ce programme.
De part sa nature "fantôme", il est difficile à dépister et à éliminer.

Afin d'obtenir un succès asymétrique dans la consommation de ressources, un tel programme d'attaque ne doit installer aucun TCB (Transmission Control Block) sur le kernel de la machine attaquante. Ceci permet de s'assurer que les activités de l'attaquant ne seront pas directement contraintes par les limitations de grain de côté-client. Il est également important de surveiller le nombre de processus du côté client  afin qu'il ne se développe avec le nombre de connexions de TCP. Naptha le fait en évitant complètement l'utilisation de la pile de TCP/IP, et ouvre à la place ses propres raw sockets. En fait, dans une attaque Naptha de cadence élevée, la largeur de bande du réseau pose plus problème que les ressources de l'hôte attaquant.

Naptha a également des capacités de cadence de connexion limitée. Dans une variation de l'attaque, des connexions sont établies à une cadence élevée et la victime est laissée avec des milliers de ports ouverts, et toutes les ressources sont consommées avant le time out. Dans un autre scénario, des connexions sont établies à une cadence lente pour éviter des protections de SYN flood.
Le nombre de connexions et de la cadence de l'établissement nécessaire pour créer un DoS dépend d'un certain nombre de facteurs. Les différents systèmes d'exploitation ont différents seuils de tolérance des nombres de connexion, des nombres de fichier, de mémoire de processus, etc... L'application fonctionnant sur ce port peut également avoir ses propres runlevels de ressource. Quelques applications engendrent un nouveau processus pour chaque connexion. La vitesse de l'unité de traitement arithmétique et de la quantité de mémoire dans un système affecte également sa résistance à une attaque de Naptha. Pour finir, le réseau lui-même joue son rôle.

En conclusion, l'attaque Naptha montre comment une Ressource Starvation peut être sérieuse. Il n'y a pas, clairement, de difficulté évidente pour ce problème mais un certain nombre d'idées prometteuses.

Recommendations

1. Limitez la quantité de services fonctionnant sur n'importe quel système que vous suspectez pouvoir être victime d'une attaque Naptha, particulièrement les services d'accès publics.

2. Limitez l'accès des clients pouvant se connecter aux ports TCP exposés sur un système par l'intermédiaire des techniques de Firewalling. Sur les systèmes publics ceci peut être impossible, mais ils devraient être limité au strict minimum.

3. Assurez-vous que tout le matériel, tel que les routeurs et firewall, est correctement configuré et vous filtrez les entrées et sorties. (Voir RFC 2267)

4. Sur les systèmes Unix, employez inetd ou plus probablement tcpserver de Dan Bernstein (http://cr.yp.to/ucspi-tcp.html) pour limiter les processus engendrés par les démons. Bien que ceci n'empêchera pas les ressources d'un démon particulier d'être sur-utilisé, il est possible d'empêcher des démons de tomber en panne le serveur. Ceci peut permettre au serveur de récupérer.

5. Sur les systèmes qui ont des réglages pour différentes minuteries et keep alive TCP, ceux-ci peuvent être ajustés pour tenir compte potentiellement d'une reprise plus rapide (supposant que le système n'est pas tombée en panne suite au naphta). Par exemple, les configurations keep alive TCP sur Linux kernel 2.2 pourraient accélérer le temps de reprise :

# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
# cat /proc/sys/net/ipv4/tcp_max_ka_probes
5
# echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes
# echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes

Dans l'exemple ci-dessus le temps keepalive est ajusté de 2 heures sur 30 en second lieu, et le nombre de sondes keepalive est ajusté de 9 sur 2. Il ajuste également le nombre maximum des sondes envoyées pour être 100 au lieu juste de 5.

6. Les exploits écrits pour démontrer l'attaque ont été distribués par le CERT mais seulement aux responsable sécurité des constructeurs d'OS. Le code ne sera pas distribué au public. Cependant, l'information ci-dessous servira une "empreinte digitale" pour que les identifications détectent le code de démonstration. Notez que le code lui-même pourrait être facilement modifié pour changer l'empreinte digitale, ainsi ce n'est pas une méthode de sécurité de détecter une attaque de Naphta.

IP:
TOS = Low Delay
ID = 413
TCP:
FLAGS = SYN
SEQ ID = 6060842
WINDOW = 512

Snort (http://www.snort.org) est un petit IDS libre. Voici un filtre Snort pour Naptha :

alert tcp any any <> any any (flags:S; seq: 6060842; id: 413; msg: "Naptha DoS Attack, see http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";)