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 catgorie de vulnrabilits DoS a t dcouverte, et Naphta est le nom gnrique la dsignant. Les vulnrabilits proviennent de faiblesses dans la manire dont la pile TCP/IP et les applications rseau manipulent l'tat d'une connexion TCP.

Systmes Affects

Une forte proportion des applications et systmes rseau

Notes

Compaq - Tru64 UNIX V4.0F

Deux services ont t tests, 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 dgradation vidente d'excution sur l'hte de Tru64 UNIX (sauf que d'autres tentatives de requtes sur le portmapper n'ont pas aboutie). La commande de netstat a montr une valeur quilibre de 4100 connexions TABLIES.

Cependant, envoyer quelques 100 paquets au TCP 79 a eu comme consquence la cration de trop de processus du dmon fingerd pour que le systme continue l'excution normale. La tentative de commencer un nouveau processus d'un login shell a eu comme consquence l'erreur "no more process". Il est possible que l'attaque du dmon fingerd aurait t moins pertinente avec une configuration diffrente d'inetd, ou avec diffrents paramtres du kernel.

FreeBSD - FreeBSD 4.0-REL

En testant FreeBSD, quelques dmons/ports spcifiques ont t viss. Pour certains, la stabilit du systme dans l'ensemble peut tre affecte. Les dmons viss lors de ce test ne sont pas ncessairement fautifs pour les problmes encourus.

SSH
Est devenu inutilisable aprs 495 connexions au port ssh. Chaque connexion a commenc une instance du dmon qui a rapidement puis les traitements disponibles de fichier ; le systme signale "too many open files in the system". Aprs approximativement 30 minutes les connexions commencent se terminer et le systme redevient utilisable.

NFS
Stoppe le fonctionnement aprs 964 paquets au port de NFS. Tandis que le reste du systme ne semblait pas affect, les connexions ne se sont pas termine.

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 affects sur d'autres variantes de Linux et d'Unix. General Linux - Linux 2.0 kernel-based systems TELNET
Le dmon telnetd est mort aprs 500 paquets dans l'tat TABLI. Le dmon telnetd n'a jamais rcupr, et ainsi beaucoup de ressources ont t puises, comme la mmoire, tel point que le systme a d tre relanc pour rcuprer.

RPC
Le dmon RPC a arrt de rpondre aprs 442 paquets dans l'tat TABLI. Comme l'attaque telnetd, on a compromis de la mmoire et d'autres ressources et le systme a d tre relanc pour rcuprer. Hewlett-Packard - HP-UX 11.00 Deux services ont t tests, 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 rpondre aux paquets de Naptha aprs plusieurs centaines de la mme adresses IP. Cependant, jusqu' ce qu'il soit possible de faire rpondre le telnetd avec "Telnet device drivers missing: No such device". Il rcupre tout de mme assez vite.

PORTMAPPER
Aprs plusieurs centaines de sessions de Naptha TCP, une session de telnet au port 111 sera immdiatement dconnecte. Cet tat cass dure beaucoup plus longtemps que le problme 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 aprs 1010 paquets. Le port 135 (loc-srv) est mort aprs 7929 paquets. A noter que si le port 139 avait t prcdemment dtruit par Naptha, le port 135 serai mort aprs 2 paquets. Si l'attaque Naptha faisait une pause, le port 135 rcuprerait mais serait immdiatement indisponible si l'attaque de Naptha tait reprise. Quand le port 135 est mort, l'utilisation de l'unit de traitement arithmtique serait utilise 100% et demeurerait dans cet tat jusqu' une rinitialisation.

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 aprs 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 rcupr de mmoire aprs 12 heures laisses en veille. Red Hat - Red Hat Linux 6.1 Kernel 2.2.12 SSH
En utilisant l'tat TABLI, le sshd est devenu inutilisable aprs 519 paquets. L'utilisation de l'unit de traitement arithmtique a augmente, rendant l'activit sur le systme lente. Les processus dmon engendrs ont empcher de rcuprer, bien que par la suite toutes les connexions en tat TABLI se sont termines aprs environ 2 heures.

RPC
En utilisant l'tat TABLI, le dmon RPC a cess de rpondre aux requtes lgitimes au bout d'environ 200 paquets, et est devenu inutilisable aprs 994 paquets. Le dmon a d tre stopp et relanc pour rcuprer.

SRP Telnet daemon
Aprs 92 paquets, le dmon telnet SRP-enabled a t surcharg. La reprise a exig une rinitialisation pour effacer les processus et les connexions TABLIE, qui ont eu des problmes 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 rsister convenablement aux attaques Naptha. L'envoi de 20000 paquets au port TCP 111 n'a caus aucune dgradation vidente d'excution sur l'hte Irix (sauf que d'autres tentatives de requtes sur portmapper n'ont pas aboutie). La commande netstat a montr une valeur quilibre de 195 connexions TABLIES.

Cependant, envoyer quelques 100 paquets au TCP 5232 a eu comme consquence la cration de trop de processus du dmon dgl pour que le systme continue l'excution normale. La tentative de commencer un nouveau processus d'un login shell a eu comme consquence l'erreur "no more process". Il est possible que l'attaque du dmon dgl aurait t moins pertinente avec une configuration diffrente d'inetd, ou avec diffrents paramtres du kernel.

Slackware - Slackware Linux 4.0 TELNET
Aprs 224 paquets TABLI, le service TCP est tomb en panne et aucun autre processus ne peut tre lancer. Un rebootage sauvage est ncessaire pour rcuprer (ctrl-alt-suppr ne fonctionne pas).

RPC
Aprs 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 ncessaire pour rcuprer.

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 dbranche. Au bout de 1700 sessions TCP Naptha, une session de telnet sera relie 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 arrte, par la suite le telnet rcuprera. La dure pendant laquelle il est cass dpend de la vitesse et de la longueur de l'attaque Naptha ainsi que d'autres facteurs. Le temps d'arrt typique tait une heure.

PORTMAPPER
Au bout d'environ 300 sessions TCP Naptha, une session telnet sur le port 111 est immdiatement dconnecte (normalement, elle est dconnecte quand un utilisateur entre la cl d'entre). Ce dfaut n'affecte pas d'autres services. Le temps d'arrt est variable mais dure en gnral 2 heures.

En crant un nombre assez grand de connexions TCP et en les laissant dans certains, les diffrentes applications ou le systme d'exploitation lui-mme peuvent tre mis hors service. Des attaques exploitant les connexions de TCP de cette manire 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 crer 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 dgrader de manire significative la qualit et/ou la disponibilit des services d'un systme.

DoS->RS
La Resource Starvation est un type d'attaque DoS. Ici nous avons besoin de dfinir la diffrence entre une attaque et une vulnrabilit notable. Avec des ressources rseau suffisantes disposition de l'attaquant, n'importe quel systme est vulnrable DoS->RS.
Ce qui fait de DoS->RS une mthode notable est qu'elle consomme bien plus de ressources auprs de la victime que de l'attaquant. Une diffrence importante entre des niveaux de ressource indiquent une vulnrabilit dans le systme de la victime. Cette vulnrabilit s'exploite sous forme d'exploit.

DoS->RS->TCP_STATE
Le kernel log chaque connexion TCP. Un grand nombre de connexions, indpendamment de l'activit, exigent plus de mmoire et de temps CPU. Il est thoriquement possible pour un utilisateur sur un machine avec un grand quantit de mmoire, une unit de traitement arithmtique rapide et un systme d'exploitation correctement configur de perturber un peu le systme rien qu'en utilisant des programmes standard tels que Telnet, toutefois la quantit de ressources consommes sur le systme attaquant est trop importante pour que ce ne soit pas considr comme une vulnrabilit srieuse.
Un programme d'attaque utilisant une API rseau tel que l'interface socket BSD est plus efficace et donc plus dangereux, mais n'est pas habituellement assez efficace pour exposer une vulnrabilit dangereuse sur le systme de la victime.

Dtails

Naptha est une dmonstration d'une exploit efficace de DoS->RS->TCP_STATE. Il est efficace parce qu'il n'emploie pas une traditionnelle API rseau pour initier une connexion TCP. la diffrence d'une vraie pile TCP/IP, il ne garde aucun enregistrement d'tat de connexion. il rpond 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 trs peu de ressources l'attaquant par rapport au niveau lev de ressources requise la cible. De cette faon, il peut exploiter les vulnrabilits d'un service particulier, ou la pile TCP/IP elle-mme, sur le systme de la victime.

Fonctionnement de Naphta

Bien qu'il y eut quelques travaux sur ce sujet, personne n'a dit ou a dmontr 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 lments (permettant un de cacher une partie de l'attaque sur diffrents centres serveurs).
Naptha tire en grande partie son efficacit du fait que l'attaque peut tre faite d'une faon distribue.

La premire partie envoie une squence de paquets SYN spoofs tous les ports possibles la victime. Selon les conditions du scnario d'attaque, des copies multiples de ce programme sur le mme centre serveur pourraient tre employes pour attaquer diffrents centres serveurs, ou les centres serveurs multiples pourraient attaquer une unique victime. Ceci ressemble un SYN flood, mais il y a plus.

La 2me partie fonctionne sur un rseau local o l'adresse IP serait forge, si c'tait un vrai hte. Le programme s'assure d'abord que le routeur a une entre pour cet hte fantme dans sa table ARP. Ensuite, il coute en mode promiscous les paquets entre la victime et l'hte fantme. Le programme renvoie un paquet avec les flags et numros de squences appropris. Prcisment, 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 dtecter les paquets "rguliers" de donnes ou gardez les paquets "vivants" et envoyez un ACK en rponse. Des victimes multiples pourraient tre vises par un exemple simple de ce programme.
De part sa nature "fantme", il est difficile dpister et liminer.

Afin d'obtenir un succs asymtrique 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 activits de l'attaquant ne seront pas directement contraintes par les limitations de grain de ct-client. Il est galement important de surveiller le nombre de processus du ct client  afin qu'il ne se dveloppe avec le nombre de connexions de TCP. Naptha le fait en vitant compltement l'utilisation de la pile de TCP/IP, et ouvre la place ses propres raw sockets. En fait, dans une attaque Naptha de cadence leve, la largeur de bande du rseau pose plus problme que les ressources de l'hte attaquant.

Naptha a galement des capacits de cadence de connexion limite. Dans une variation de l'attaque, des connexions sont tablies une cadence leve et la victime est laisse avec des milliers de ports ouverts, et toutes les ressources sont consommes avant le time out. Dans un autre scnario, 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 ncessaire pour crer un DoS dpend d'un certain nombre de facteurs. Les diffrents systmes d'exploitation ont diffrents seuils de tolrance des nombres de connexion, des nombres de fichier, de mmoire 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 arithmtique et de la quantit de mmoire dans un systme affecte galement sa rsistance une attaque de Naptha. Pour finir, le rseau lui-mme joue son rle.

En conclusion, l'attaque Naptha montre comment une Ressource Starvation peut tre srieuse. Il n'y a pas, clairement, de difficult vidente pour ce problme mais un certain nombre d'ides prometteuses.

Recommendations

1. Limitez la quantit de services fonctionnant sur n'importe quel systme que vous suspectez pouvoir tre victime d'une attaque Naptha, particulirement les services d'accs publics.

2. Limitez l'accs des clients pouvant se connecter aux ports TCP exposs sur un systme par l'intermdiaire des techniques de Firewalling. Sur les systmes publics ceci peut tre impossible, mais ils devraient tre limit au strict minimum.

3. Assurez-vous que tout le matriel, tel que les routeurs et firewall, est correctement configur et vous filtrez les entres et sorties. (Voir RFC 2267)

4. Sur les systmes Unix, employez inetd ou plus probablement tcpserver de Dan Bernstein (http:/cr.yp.to/ucspi-tcp.html) pour limiter les processus engendrs par les dmons. Bien que ceci n'empchera pas les ressources d'un dmon particulier d'tre sur-utilis, il est possible d'empcher des dmons de tomber en panne le serveur. Ceci peut permettre au serveur de rcuprer.

5. Sur les systmes qui ont des rglages pour diffrentes minuteries et keep alive TCP, ceux-ci peuvent tre ajusts pour tenir compte potentiellement d'une reprise plus rapide (supposant que le systme n'est pas tombe en panne suite au naphta). Par exemple, les configurations keep alive TCP sur Linux kernel 2.2 pourraient acclrer 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 envoyes pour tre 100 au lieu juste de 5.

6. Les exploits crits pour dmontrer l'attaque ont t distribus par le CERT mais seulement aux responsable scurit 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 dtectent le code de dmonstration. Notez que le code lui-mme pourrait tre facilement modifi pour changer l'empreinte digitale, ainsi ce n'est pas une mthode de scurit de dtecter 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";)