<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<META name="generator" content="HTML Tidy, see www.w3.org">
<!-- this stylesheet will later on be added by lfparser automatically: -->
<STYLE type="text/css">
<!--
pre { font-familiy:monospace,Courier }
p.code { width:80%; alignment:center; background-color:#aedbe8; border-style:no ne; border-width:medium; border-color:#aedbe8; padding:0.1cm ; text-align:left }
-->
</STYLE>
</HEAD>
<BODY>
<h1>Les attaques externes</h1>
<H4>ArticleCategory:</H4>
System Administration
<H4>AuthorImage:</H4>
<IMG src="../../common/images/article282/Bat.gif" width=
"104" height="54" alt="Eric Detoisien">
<H4>TranslationInfo:[Author and translation history]</H4>
<P>original in fr <a href="mailto:valgasu(at)club-internet.fr">Eric
Detoisien</A> </P>
<H4>AboutTheAuthor</H4>
<P>
Eric Detoisien est sp�cialiste en s�curit� informatique.
Passionn� par tous les domaines li�s � la s�curit�, il fait partie
des experts du groupe rstack - www.rstack.org -
</P>
<h4>Abstract</h4>
<p>
Cet article a �t� publi� dans un num�ro sp�cial sur la s�curit� de Linux
Magazine France. L'�diteur, les auteurs, les traducteurs ont aimablement
accept� que tous les articles de ce num�ro hors-s�rie soient publi�s dans
LinuxFocus. En cons�quence, LinuxFocus vous "offrira" ces articles au fur et
� mesure de leur traduction en Anglais. Merci � toutes les personnes qui se
sont investies dans ce travail. Ce r�sum� sera reproduit pour chaque article
ayant la m�me origine.
<p>
Cet article pr�sente les diff�rentes attaques externes qu'un pirate peut
utiliser � l'encontre des machines d'un r�seau. Nous aborderons ce sujet au
travers des principales attaques r�seaux, des attaques via les applications
et des attaques de type d�ni de service.
</P>
<H4>ArticleIllustration:</H4>
<img src="../../common/images/article282/attack_th.jpg" alt="Attacks" hspace="10" width="300" height="177">
<H4>ArticleBody:[The article body]</H4>
<H1>Les attaques r�seaux</H1>
<P>
Les attaques r�seaux s'appuient sur des vuln�rabilit�s li�es directement
aux protocoles ou � leur impl�mentation. Il en existe un grand
nombre. N�anmoins, la plupart d'entre elles ne sont que des variantes des
cinq attaques r�seaux les plus connues aujourd'hui.
</P>
<H2>Fragments attacks</H2>
Cette attaque outrepasse la protection des �quipements de filtrage IP. Pour
sa mise en pratique, les pirates utilisent deux m�thodes : les Tiny
Fragments et le Fragment Overlapping. Ces attaques �tant historiques, les
pare-feux actuels les prennent en compte depuis longtemps dans leur
impl�mentation.
<H3>Tiny Fragments</H3>
<P>
D'apr�s la RFC (<em>Request For Comment</em>) 791 (IP), tous les noeuds
Internet (routeurs) doivent pouvoir transmettre des paquets d'une taille de
68 octets sans les fragmenter d'avantage. En effet, la taille minimale de
l'en-t�te d'un paquet IP est de 20 octets sans options. Lorsqu'elles sont
pr�sentes, la taille maximale de l'en-t�te est de 60 octets. Le champ IHL
(<em>Internet Header Length</em>) contient la longueur de l'en-t�te en mots
de 32 bits. Ce champ occupant 4 bits, le nombre de valeurs possibles
vaut de 2^4 - 1 = 15 (il ne peut pas prendre la valeur 0000). La taille
maximale de l'en-t�te est donc bien 15*4 = 60 octets. Enfin, le champ
<em>Fragment Offset</em> qui indique le d�calage du premier octet du
fragment par rapport au datagramme complet est mesur�e en blocs de 8 octets.
Un fragment de donn�es occupe donc au moins 8 octets. Nous arrivons bien � un
total de 68 octets.
</p><p>
L'attaque consiste � fragmenter sur deux paquets IP une demande de
connexion TCP. Le premier paquet IP de 68 octets ne contient comme
donn�es que les 8 premiers octets de l'en-t�te TCP (ports source et
destination ainsi que le num�ro de s�quence). Les donn�es du second
paquet IP renferment alors la demande de connexion TCP (flag SYN � 1
et flag ACK � 0).
</p><p>
Or, les filtres IP appliquent la m�me r�gle de filtrage � tous les
fragments d'un paquet. Le filtrage du premier fragment (Fragment
Offset �gal � 0) d�terminant cette r�gle elle s'applique donc aux
autres (Fragment Offset �gal � 1) sans aucune autre forme de
v�rification. Ainsi, lors de la d�fragmentation au niveau IP de la
machine cible, le paquet de demande de connexion est reconstitu� et
pass� � la couche TCP. La connexion s'�tablit alors malgr� le filtre
IP.
</p><p>
Les figures 1 et 2 montrent
les deux fragments et la figure 3 le paquet
d�fragment� au niveau de la machine cible :
</p><p>
<p>Fig.1: Fragment 1<br>
<img src="../../common/images/article282/Tiny-Frag-1.jpg" alt=
"Tiny-Frag-1" width="424" height="174"><br>
Fig.2: Fragment 2<br>
<img src="../../common/images/article282/Tiny-Frag-2.jpg" alt=
"Tiny-Frag-2" width="363" height="215"><br>
Fig.3: Paquet d�fragment�<br>
<img src="../../common/images/article282/Tiny-Frag-3.jpg" alt=
"Tiny-Frag-3" width="374" height="255"></p>
</P>
<H3>Fragment Overlapping</H3>
<P>
Toujours d'apr�s la RFC 791 (IP), si deux fragments IP se superposent,
le deuxi�me �crase le premier. L'attaque consiste � forger deux
fragments d'un paquet IP. Le filtre IP accepte le premier de 68
octets (voir Tiny Fragments) car il ne contient aucune demande de
connexion TCP (flag SYN = 0 et flag ACK = 0). Cette r�gle
d'acceptation s'applique, l� encore, aux autres fragments du
paquet. Le deuxi�me (avec un Fragment Offset �gale � 1) contenant les
v�ritables donn�es de connexion est alors accept� par le filtre
IP. Ainsi, lors de la d�fragmentation les donn�es du deuxi�me
fragment �crasent celles du premier � partir de la fin du 8�me octet
(car le fragment offset est �gal � 1). Le paquet r�assembl� constitue
donc une demande de connexion valide pour la machine cible. La
connexion s'�tablit malgr� le filtre IP.
</p><p>
Les figures 4 et 5
montrent les deux fragments et la figure 6 le
paquet d�fragment� au niveau de la machine cible :
</p><p>
<p>Fig.4: Fragment 1<br>
<img src="../../common/images/article282/Tiny-Frag-4.jpg" alt=
"Tiny-Frag-4" width="427" height="237"><br>
Fig.5: Fragment 2<br>
<img src="../../common/images/article282/Tiny-Frag-5.jpg" alt=
"Tiny-Frag-5" width="379" height="206"><br>
Fig.6: Paquet d�fragment�<br>
<img src="../../common/images/article282/Tiny-Frag-6.jpg" alt=
"Tiny-Frag-6" width="376" height="237"></p>
</P>
<H2>IP Spoofing</H2>
<p>
Le but de cette attaque est l'usurpation de l'adresse IP d'une
machine. Ceci permet au pirate de cacher la source de son
attaque (utilis�e dans les d�nis de services dont nous discuterons plus
tard) ou de profiter d'une relation de confiance entre deux
machines. Nous expliquerons donc ici cette deuxi�me utilisation de l'IP
Spoofing.
</p><p>
Le principe de base de cette attaque consiste � forger ses propres paquets
IP (avec des programmes comme <code>hping2</code> ou <code>nemesis</code>)
dans lesquels le pirate modifiera, entre autres, l'adresse IP source. L'IP
Spoofing est souvent qualifi� d'attaque aveugle (ou Blind Spoofing).
Effectivement, les r�ponses �ventuelles des paquets envoy�s ne peuvent pas
arriver sur la machine du pirate puisque la source est falsifi�e. Ils se
dirigent donc vers la machine spoof�e. Il existe n�anmoins deux m�thodes
pour r�cup�rer des r�ponses :
<OL>
<LI>le <em>Source Routing</em> : le protocole IP poss�de une option
appel�e Source Routing autorisant la sp�cification du chemin que
doivent suivre les paquets IP. Ce chemin est constitu� d'une suite
d'adresses IP des routeurs que les paquets vont devoir emprunter. Il
suffit au pirate d'indiquer un chemin, pour le retour des paquets,
jusqu'� un routeur qu'il contr�le. De nos jours, la plupart des
impl�mentations des piles TCP/IP rejettent les paquets avec cette
option;
<LI>le <em>Reroutage</em> : les tables des routeurs utilisant
le protocole de routage RIP peuvent �tre modifi�es en leur
envoyant des paquets RIP avec de nouvelles indications de
routage . Ceci dans le but de rerouter les paquets vers un
routeur que le pirate ma�trise.
</OL>
Ces techniques ne sont plus (ou difficilement) utilisables :
l'attaque est donc men�e sans avoir connaissance des paquets �mis par
le serveur cible.
</p><p>
Le Blind Spoofing s'utilise contre des services de type rlogin ou
rsh. En effet, leur m�canisme d'authentification se base uniquement
sur l'adresse IP source de la machine cliente. Cette attaque
relativement bien connue (surtout gr�ce � Kevin Mitnick qui l'avait
utilis�e contre la machine de Tsutomu Shimomura en 1994) se d�roule en
plusieurs �tapes :
<UL>
<LI>d�termination de l'adresse IP de la machine de confiance en
utilisant par exemple <code>showmount -e</code> qui montre o�
sont export�s les syst�mes de fichiers ou <code>rpcinfo</code>
qui apporte des informations suppl�mentaires;
<LI>mise hors service de l'h�te de confiance via un SYN Flooding par
exemple (nous aborderons les d�nis de service plus loin dans cet
article). Cela est n�cessaire pour que la machine ne puisse pas
r�pondre aux paquets envoy�s par le serveur cible. Dans le cas
contraire elle enverrait des paquets TCP RST qui mettraient fin
� l'�tablissement de la connexion;
<LI>pr�diction des num�ros de s�quence TCP : � chaque paquet
TCP est associ� un num�ro de s�quence initiale. La pile TCP/IP
du syst�me d'exploitation le g�n�re de mani�re lin�aire,
d�pendante du temps, pseudo-al�atoire ou al�atoire selon les
syst�mes. Le pirate peut uniquement appliquer cette attaque �
des syst�mes g�n�rant des num�ros de s�quence pr�visibles
(g�n�ration lin�aire ou d�pendante du temps);
<LI>l'attaque consiste � ouvrir une connexion TCP sur le port
souhait� (rsh par exemple). Pour une meilleure compr�hension,
nous allons rappeler le m�canisme d'ouverture d'une connexion
TCP. Elle s'effectue en trois phases (TCP Three Way
Handshake) :
<ol>
<li>l'initiateur envoie un paquet comportant le flag TCP SYN
et un num�ro de s�quence <em>x</em>, est envoy� � la
machine cible;</li>
<li>cette derni�re r�pond avec un paquet dont les flag TCP SYN
et ACK (avec un num�ro d'acquittement de <em>x+1</em>)
sont activ�s. Son num�ro de s�quence vaut
<em>y</em>;</li>
<li>l'initiateur renvoie un paquet contenant le flag TCP ACK
(avec un num�ro d'acquittement de <em>y+1</em>) � la
machine cible.</li>
</ol>
</UL>
Lors de l'attaque le pirate ne re�oit pas le SYN-ACK envoy� par la
cible. Pour que la connexion puisse s'�tablir, il pr�dit le num�ro
de s�quence <em>y</em> afin d'envoyer un paquet avec le bon
num�ro de ACK (<em>y+1</em>). La connexion s'�tablit alors gr�ce �
l'authentification par l'adresse IP. Le pirate peut donc envoyer une
commande au service rsh pour obtenir des droits suppl�mentaires, comme
<CODE>echo ++ >> /.rhosts</CODE>. Pour cela il forge un paquet avec le
flag TCP PSH (<em>Push</em>) : les donn�es re�ues sont
imm�diatement transmises � la couche sup�rieure, ici le service rsh,
pour que celle-ci les traitent. Il lui est alors possible de se
connecter sur la machine directement via un service de type rlogin ou
rsh sans IP Spoofing.
</p><p>
La figure 7 r�sume les �tapes de l'IP Spoofing :<br>
Pic.7: IP Spoofing appliqu� au service rsh<br>
<img src="../../common/images/article282/ip_spoof.jpg" alt=
"ip_spoof" width="325" height="179"></p>
<p>
Le pirate utilise la machine A tandis que la C repr�sente la machine
de confiance. La notion A(C) signifie que le paquet est envoy� par A
avec l'adresse IP Spoof�e de C. A noter l'existence du programme
<code>mendax</code> qui met en oeuvre ces diff�rents m�canismes de
l'IP Spoofing.
</p>
<H2>TCP Session Hijacking</H2>
<p>
Le TCP Session Hijacking permet de rediriger un flux TCP. Un pirate peut
alors outrepasser une protection par un mot de passe (comme telnet ou
ftp). La n�cessit� d'une �coute passive (sniffing) restreint le p�rim�tre
de cette attaque au r�seau physique de la cible. Avant de d�tailler
cette attaque, nous expliquerons quelques principes fondamentaux du
protocole TCP.
</p><p>
Nous ne d�voilerons pas ici les arcanes du protocole TCP, mais pr�ciserons
uniquement les points essentiels � la compr�hension de l'attaque.
L'en-t�te TCP est constitu� de plusieurs champs :
<UL>
<LI>le port source et le port destination, pour identifier la
connexion entre deux machines; </li>
<LI>le num�ro de s�quence qui identifie chacun des octets envoy�s;</li>
<LI>le num�ro d'acquittement qui correspond au num�ro d'acquittement du
dernier octet re�u;</li>
<LI>les flags, avec ceux qui vont nous int�resser sont :
<UL>
<LI>SYN qui synchronise les num�ros de s�quence lors de
l'�tablissement d'une connexion; </li>
<LI>ACK, le flag d'acquittement d'un segment TCP; </li>
<LI>PSH qui indique au r�cepteur de remonter les donn�es �
l'application.</li>
</UL>
</li>
</UL>
</p><p>
La figure 8 sch�matise l'�tablissement d'une connexion
TCP (Three Way Handshake) : <br>
Fig.8 : Three Way Handshake<br>
<img src="../../common/images/article282/tcp_hij1.jpg" alt="3way"
width="289" height="111"></p>
<p>
Dans ce cas, il s'agit de la machine A qui a initialis� une connexion TCP sur la machine B. De m�me, la figure 9
montre un transfert de donn�es TCP :<br>
Fig.9 : �change de donn�es:<br>
<img src="../../common/images/article282/tcp_hij2.jpg" alt="psh"
width="401" height="132"></p>
<p>
Les num�ros de s�quence vont �voluer en fonction du nombre d'octets de
donn�es envoy�s. Le num�ro de s�quence est repr�sent� par
<em>Seq</em>, le num�ro d'acquittement se trouve apr�s les flags PSH
et ACK et le nombre d'octets de donn�es envoy� se trouve entre
parenth�ses.
</p><p>
Cette attaque cr�e un �tat de d�synchronisation de chaque c�t� de la
connexion TCP, rendant possible le vol de session. Une connexion est
d�synchronis�e lorsque le num�ro de s�quence du prochain octet envoy� par
la machine A est diff�rent du num�ro de s�quence du prochain octet �
recevoir par B. Et r�ciproquement, il y a d�synchronisation lorsque le
num�ro de s�quence du prochain octet envoy� par la machine B est diff�rent
du num�ro de s�quence du prochain octet � recevoir par A.
</p><p>
Dans l'exemple de la figure 9, � la fin de la
premi�re �tape quand B re�oit son paquet, A attends un paquet avec un
num�ro d'acquittement de <em>x+60</em>. Si le prochain paquet qu'envoie B
n'a pas ce num�ro d'acquittement alors A et B sont dits d�synchronis�s.
</p><p>
Concr�tement, un pirate avec une machine C veut voler une session
Telnet �tablie entre les machines A et B. Dans un premier temps, la
machine C sniffe le traffic Telnet (port TCP 23) entre A et B. Une
fois que le pirate estime que A a eu le temps de s'authentifier aupr�s
du service Telnet de la machine B, il d�synchronise la machine A
par rapport � B. Pour cela, il forge alors un paquet avec, comme adresse
IP source, celle de la machine A et le num�ro d'acquittement TCP
attendu par B. La machine B accepte donc ce paquet. En plus de
d�synchroniser la connexion TCP ce paquet permet au pirate
d'injecter une commande via la session Telnet pr�alablement �tablie
par A. En effet, ce paquet peut transporter des donn�es (flag PSH �gal
� 1).
</p><p>
La figure 10 r�sume cette attaque :<br>
Fig.10: TCP Session Hijacking<br>
<img src="../../common/images/article282/tcp_hij3.jpg" alt=
"hijacking" width="399" height="249"></p>
<p>
La machine B accepte bien la commande envoy�e par C, elle acquitte
donc ce paquet en envoyant un paquet � A avec le flag ACK. Entre
temps, si A a envoy� un paquet � B celui-ci n'a pas �t� accept� du
fait de num�ro de s�quence qui n'est pas celui attendu par B.
</p><p>
Un probl�me appara�t alors : le Ack Storm. Il s'agit d'une multitude
de ACK qui sont g�n�r�s. Ils apparaissent lorsque A envoie un paquet
TCP avec un num�ro de s�quence non valide (car A est d�synchronis�) B
le jette et envoie � A un ACK avec le num�ro de s�quence qu'il
attend. De son c�t�, A re�oit ce ACK et comme le num�ro de s�quence ne
correspond pas � celui attendu il renvoie � son tour un ACK � B et B
refait la m�me chose...
</p><p>
Ce probl�me du Ack Storm peut �tre r�gl� si le pirate utilise l'ARP
Spoofing. Dans ce cas, la machine C empoisonnera le cache ARP de la
machine B en lui indiquant que l'adresse IP de A est d�sormais
associ�e � l'adresse MAC de C. Ces diff�rentes techniques sont
impl�ment�es par le programme <code>hunt</code>.
</p>
<H2>ARP Spoofing</H2>
<p>
Cette attaque, appel�e aussi ARP Redirect, redirige le trafic r�seau
d'une ou plusieurs machine vers la machine du pirate. Elle s'effectue
sur le r�seau physique des victimes. Au pr�alable nous ferons un
rappel sur l'utilit� et le fonctionnement du protocole ARP.
</p><p>
Le protocole ARP (<em>Address Resolution Protocol</em>) impl�mente le
m�canisme de r�solution d'une adresse IP en une adresse MAC
Ethernet. Les �quipements r�seaux communiquent en �changeant des
trames Ethernet (dans le cas d'un r�seau Ethernet bien s�r) au niveau
de la couche liaison de donn�es. Pour pouvoir �changer ces
informations il est n�cessaire que les cartes r�seau poss�dent une
adresse unique au niveau Ethernet, il s'agit de l'adresse MAC
(<em>Media Access Control</em>).
</p><p>
Quand un paquet IP doit �tre envoy� la machine exp�ditrice a besoin de
l'adresse MAC du destinataire. Pour cela une requ�te ARP en broadcast
est envoy�e � chacune des machines du r�seau physique local. Cette
requ�te pose la question : "Quelle est l'adresse MAC associ�e �
cette adresse IP ?". La machine ayant cette adresse IP r�pond via un
paquet ARP, cette r�ponse indiquant � la machine �mettrice l'adresse
MAC recherch�e. D�s lors, la machine source poss�de l'adresse MAC
correspondant � l'adresse IP destination des paquets qu'elle doit
envoyer. Cette correspondance sera gard�e pendant un certain temps au
niveau d'un cache (pour �viter de faire une nouvelle requ�te � chaque
paquet IP envoy�).
</p><p>
Cette attaque corrompt le cache de la machine victime. Le pirate
envoie des paquets ARP r�ponse � la machine cible indiquant que la
nouvelle adresse MAC correspondant � l'adresse IP d'une passerelle
(par exemple) est la sienne. La machine du pirate recevra donc tout le
trafic � destination de la passerelle, il lui suffira alors d'�couter
passivement le trafic (et/ou le modifier). Il routera ensuite les
paquets vers la v�ritable destination.
</p><p>
L'ARP Spoofing sert dans le cas o� le r�seau local utilise des
switchs. Ceux-ci redirigent les trames Ethernet sur des ports
diff�rents selon l'adresse MAC. Il est d�s lors impossible � un
sniffer de capturer des trames au-del� de son brin physique. L'ARP
Spoofing permet ainsi d'�couter le trafic entre des machines situ�es
sur des brins diff�rents au niveau du switch.
</p><p>
Pour mettre en oeuvre une attaque par ARP Spoofing, le pirate va
utiliser un g�n�rateur de paquet ARP comme <code>ARPSpoof</code> ou
<code>nemesis</code>. Soit la machine victime <code>10.0.0.171</code>,
sa passerelle par d�faut <code>10.0.0.1</code> et la machine du pirate
<code>10.0.0.227</code>. Avant l'attaque un traceroute donne comme
r�sultat :
<pre class="code">
[root@cible -> ~]$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 1.218 ms 1.061 ms 0.849 ms
</pre>
<p>
Et le cache ARP de la machine cible est :
<pre class="code">
[root@cible -> ~]$ arp
Address HWtype HWAddress Flags Mask Iface
10.0.0.1 ether 00:b0:c2:88:de:65 C eth0
10.0.0.227 ether 00:00:86:35:c9:3f C eth0
</pre>
<p>
Le pirate lance alors <code>ARPSpoof</code> :
<pre class="code">
[root@pirate -> ~]$ arpspoof -t 10.0.0.171 10.0.0.1
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
</pre>
<p>
Les paquets envoy�s sont des paquets ARP empoisonnant le cache ARP de
la machine <code>10.0.0.171</code> avec des ARP Reply indiquant que
l'adresse MAC associ�e � <code>10.0.0.1</code> est maintenant
<code>00:00:86:35:c9:3f</code>.
</p><p>
D�sormais, le cache ARP de la machine <code>10.0.0.171</code> est :
<pre class="code">
[root@cible -> ~]$ arp
Address HWtype HWAddress Flags Mask Iface
10.0.0.1 ether 00:00:86:35:c9:3f C eth0
10.0.0.227 ether 00:00:86:35:c9:3f C eth0
</pre>
<p>
Pour v�rifier que le trafic passe maintenant par la machine
<code>10.0.0.227</code> il suffit de faire un nouveau traceroute vers
la passerelle <code>10.0.0.1</code> :
<pre class="code">
[root@cible -> ~]$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
1 10.0.0.227 (10.0.0.227) 1.712 ms 1.465 ms 1.501 ms
2 10.0.0.1 (10.0.0.1) 2.238 ms 2.121 ms 2.169 ms
</pre>
<p>
Le pirate est d�sormais capable de sniffer le trafic de la machine
<code>10.0.0.171</code> vers <code>10.0.0.1</code>. Il ne faut pas que le
pirate oublie d'activer le routage IP sur sa machine
<code>10.0.0.227</code> (avec l'IP Forwarding - activer la cl�
<code> net.ipv4.ip_forward</code> dans <code>/etc/sysctl.conf</code> ou
<code>fragrouter</code>).
</p>
<H2>DNS Spoofing</H2>
<p>
Le protocole DNS (<em>Domain Name System</em>) a pour r�le de
convertir un nom de domaine (par exemple www.test.com) en son adresse
IP (par exemple <code>192.168.0.1</code>) et r�ciproquement, � savoir
convertir une adresse IP en un nom de domaine. Cette attaque consiste
� faire parvenir de fausses r�ponses aux requ�tes DNS �misent par une
victime. Il existe deux m�thodes principales pour effectuer cette
attaque.
</p>
<H3>DNS ID Spoofing</H3>
<p>
L'en-t�te du protocole DNS comporte un champ identification qui permet
de faire correspondre les r�ponses aux demandes. L'objectif du DNS ID
Spoofing est de renvoyer une fausse r�ponse � une requ�te DNS
avant le serveur DNS. Pour cela il faut pr�dire l'ID de la
demande. En local, il est simple de le pr�dire en sniffant le
r�seau. N�anmoins, cela s'av�re plus compliqu� � distance. Cependant
il existe plusieurs m�thodes :
<ul>
<li>essayer toutes les possibilit�s du champ ID. Cette m�thode n'est
pas tr�s r�aliste puisqu'il y a 65535 possibilit�s pour le champ
ID (car ce champ est cod� sur 16 bits);</li>
<li>envoyer quelques centaines de requ�tes DNS dans l'ordre. Cette
m�thode est bien �videmment peu fiable;</li>
<li>trouver un serveur qui g�n�re des ID pr�visibles (incr�mentation
de 1 de l'ID par exemple), ce genre de faille existe sur
certaines version de Bind ou des machines Windows 9x.</li>
</ul>
</p><p>
Dans tous les cas, il est n�cessaire de r�pondre avant le serveur DNS,
en le faisant tomber via un d�ni de service par exemple.
</p><p>
Pour parvenir � ses fins, l'attaquant doit contr�ler un serveur DNS
(<code>ns.attaquant.com</code>) ayant autorit� sur le domaine
<code>attaquant.com</code>. Le serveur DNS cible
(<code>ns.cible.com</code>) est suppos� avoir des num�ros de s�quence
pr�visibles (s'incr�mentant de 1 � chaque nouvelle requ�te).
</p><p>
L'attaque se d�compose en quatre �tapes :
<ol>
<li>l'attaquant envoie une requ�te DNS pour le nom
<code>www.attaquant.com</code> au serveur DNS du domaine
<code>cible.com</code> comme le montre la figure 11;<br>
Fig.11: Envoi de la requ�te DNS � <code>ns.cible.com</code><br>
<img src="../../common/images/article282/dns_spoof1.jpg" alt=
"dnsspoof1" width="452" height="64"> <br>
<br></li>
<li>le serveur DNS cible a donc relay� la demande au DNS du domaine
<code>attaquant.com</code>;</li>
<li>l'attaquant est capable de sniffer la requ�te pour r�cup�rer son
ID (dans notre exemple l'ID a une valeur de 100); </li>
<li>l'attaque falsifie l'adresse IP associ�e � un nom de machine,
ici la machine victime est <code>www.spoofed.com</code> qui a
normalement l'adresse IP <code>192.168.0.1</code>. Le pirate
�met une requ�te DNS de r�solution du nom
<code>www.spoofed.com</code> vers
<code>ns.cible.com</code>. Imm�diatement apr�s, il envoie
une multitude de r�ponses DNS falsifi�es (donnant comme adresse
IP celle du site de l'attaquant <code>10.0.0.1</code>) � cette
m�me requ�te en ayant spoof� l'adresse IP source avec celle du
serveur DNS du domaine <code>spoofed.com</code>. L'ID de chaque
r�ponse sera incr�ment� de 1 � partir de celui r�cup�r� lors de
la deuxi�me �tape (ID = 100) pour augmenter la chance de tomber
sur le bon num�ro d'ID r�ponse, dans le cas o�
<code>ns.cible.com</code> aurait du r�pondre � d'autres requ�tes
et donc incr�ment� son ID DNS. La figure 12 d�taille cette �tape.<BR>
Fig.12: DNS ID Spoofing<br>
<img src="../../common/images/article282/dns_spoof2.jpg" alt=
"dnsspoof2" width="462" height="196"> <br>
<br>
<p></p>
</li>
</ol>
Le cache du serveur DNS cible est donc corrompu, et la prochaine
machine demandant une r�solution du nom <code>www.spoofed.com</code>
r�cup�rera l'adresse IP de la machine de l'attaquant et sera redirig�e
vers son site qui pourra �tre une copie du vrai site pour tromper les
internautes et leur voler des informations confidentielles.
</p>
<H3>DNS Cache Poisoning</H3>
<p>
Les serveurs DNS poss�dent un cache gardant en local, pendant un
certain temps, les r�ponses de requ�tes pass�es. Ceci pour �viter de
perdre du temps � interroger chaque fois le serveur de nom ayant
autorit� sur le domaine demand�. Ce deuxi�me type de DNS Spoofing va
consister � corrompre ce cache avec de fausses informations. Voici un
exemple de cache poisoning :
</p><p>
Les conditions de l'exemple pr�c�dent sont toujours valables. Voici
les diff�rentes �tapes de l'attaque :
<ul>
<li>envoyer une requ�te DNS de r�solution du nom
<code>www.attaquant.com</code> au serveur DNS du domaine
<code>cible.com</code>;</li>
<li>Le serveur DNS cible envoie donc une requ�te portant sur une
r�solution du nom <code>www.attaquant.com</code> au serveur DNS
de l'attaquant; </li>
<li>Le serveur DNS de l'attaquant enverra une r�ponse avec des
enregistrements falsifi�s qui permettront d'assigner un nom de
machine avec une adresse IP appartenant � l'attaquant. Par
exemple, le site <code>www.cible.com</code> pourra avoir un
enregistrement DNS falsifi� renvoyant l'adresse IP de
<code>www.attaquant.com</code> au lieu de la bonne adresse IP.</li>
</ul>
</p>
<H1>Les attaques applicatives</H1>
<P>
Les attaques applicatives s'appuient principalement sur des
vuln�rabilit�s sp�cifiques aux applications utilis�es. Cependant,
certaines attaques peuvent �tre class�es par type.
</P>
<H2>Les probl�mes de configuration</H2>
<P>
Un des premiers probl�mes de s�curit� engendr� par les applications
est celui des erreurs de configurations. Nous distinguerons deux types
d'erreurs : les installations par d�faut et les mauvaises
configurations � proprement parler.
</p><p>
Des logiciels, comme les serveurs Web, install�s par d�faut ont
souvent des sites exemples qui peuvent �tre utilis�s par des pirates
pour acc�der � des informations confidentielles. Par exemple, il peut
y avoir des scripts permettant d'obtenir les sources des pages
dynamiques ou des informations sur le syst�me utilis�. En outre, lors
d'une telle installation une interface d'administration � distance est
disponible avec un login/mot de passe par d�faut (trouvable dans le
guide d'administration de l'application). Le pirate a donc la main sur
le site et peut le modifier selon son bon vouloir.
</p><p>
Les principales failles g�n�r�es par une mauvaise configuration sont
des listes d'acc�s mal param�tr�es. Le pirate acc�de alors � des pages
et autres bases de donn�es priv�es.
</p><p>
Comme exemple classique de probl�me de configuration, les erreurs de
param�trage du serveur Web Lotus Domino sont courantes. En effet, lors
de l'installation de ce serveur, des bases Lotus de configuration sont
accessibles sans aucune liste de contr�le d'acc�s. Concr�tement, si
la base Lotus <em>names.nsf</em> est accessible via un navigateur Web
sans demande d'authentification, il est alors possible d'obtenir de
nombreuses informations comme le nom de tous les utilisateurs
Lotus. Cette base n'est qu'un exemple, et Lotus Domino en contient un
nombre important de sensibles.
</P>
<H2>Les "bugs"</H2>
<P>
Une mauvaise programmation des logiciels entra�ne obligatoirement des
"bugs". Ceux-ci seront la source des failles de s�curit� les plus
importantes. Ces vuln�rabilit�s quand elles sont d�couvertes vont
permettre d'ex�cuter des commandes non autoris�es, obtenir le source
de pages dynamiques, rendre indisponible un service, prendre la main
sur la machine, etc. Les plus connus de ces "bugs" et les plus
int�ressants en ce qui concerne leur exploitation sont les buffer
overflow.
</P>
<H2>Les buffer overflow</H2>
<P>
Le d�passement de pile est une faille due � une mauvaise
programmation. Effectivement, un buffer overflow appara�t quand une
variable pass�e en argument d'une fonction est recopi�e dans un buffer
sans que sa taille n'aie �t� v�rifi�e. Il suffit que la variable ait
une taille sup�rieure � l'espace m�moire r�serv� pour ce buffer pour
qu'un d�passement de pile se produise. Celui-ci sera exploit� en
passant dans la variable un fragment de programme capable de faire
d�marrer un shell tout en obligeant ce d�bordement de pile � se
produire. Dans le cas o� un pirate r�ussi cette attaque il obtiendra
alors le moyen d'ex�cuter � distance des commandes sur la machine
cible avec les droits de l'application attaqu�e. Le buffer overflow et
son exploitation ont �t� le sujet d'une s�rie d'articles sur la programmation
s�curis�e :<br>
</P>
<ul>
<li><a href="../January2001/article182.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 1</a></li>
<li><a href="../March2001/article183.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 2: m�moire, pile et
fonctions, shellcode</a></li>
<li><a href="../May2001/article190.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 3: d�bordements de buffer</a></li>
<li><a href="../July2001/article191.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 4: cha�nes de format</a></li>
<li><a href="../September2001/article198.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 5: race
conditions</a></li>
<li><a href="../November2001/article203.shtml">Eviter les failles de s�curit�
lors du d�veloppement d'une application - Partie 6: scripts CGI</a></li>
</ul>
<H2>Les scripts</H2>
<P>
Une mauvaise programmation des scripts a souvent une r�percution sur
la s�curit� d'un syst�me. En effet, il existe des moyens d'exploiter
des failles de scripts d�velopp�s en Perl qui permettront de lire des
fichiers hors racine Web ou d'ex�cuter des commandes non
autoris�es. Ces probl�mes de programmation ont �t� �voqu�s dans l'un des
articles ci-dessus, sur les failles des d�veloppements en Perl et PHP
(Partie 6, les scripts CGI).
</P>
<H2>Man in the middle</H2>
<P>
L'objectif principal de cette attaque est de d�tourner le trafic entre
deux machines. Cela pour intercepter, modifier ou d�truire les donn�es
transmises au cours de la communication. Cette attaque est plus un
concept qu'une attaque � part enti�re. Il existe plusieurs attaques
mettant en oeuvre ce principe du Man in The Middle, comme le DNS Man
in the Middle qui qu'une utilisation du DNS Spoofing pour d�tourner
le trafic entre un client et un serveur Web. De m�me, une application
r�cente a �t� �labor�e pour d�tourner du trafic SSH.
</P>
<H1>Les d�nis de service</H1>
<P>
Cette attaque porte bien son nom puisque qu'elle aboutira �
l'indisponibilit� du service (application sp�cifique) ou de la machine
vis�e. Nous distinguerons deux types de d�ni de services, d'une part
ceux dont l'origine est l'exploitation d'un bug d'une application et
d'autre part ceux dus � une mauvaise impl�mentation d'un protocole ou
� des faiblesses de celui-ci.
</P>
<H2>Les d�nis de service applicatifs</H2>
<P>
Tout comme les vuln�rabilit�s d'une application entra�nent la
possibilit� de prendre le contr�le d'une machine (exemple du buffer
overflow), elles peuvent aussi amener � un d�ni de
service. L'application sera alors indisponible par saturation des
ressources qui lui sont allou�es ou un crash de celle-ci.
</P>
<H2>Les d�nis de service r�seaux</H2>
<p>
Il existe diff�rents types de d�ni de service utilisant les
sp�cificit�s des protocoles de la pile TCP/IP.
</p>
<H3>SYN Flooding</H3>
<P>
Nous avons vu qu'une connexion TCP s'�tablie en trois phases (TCP
Three Way Handshake). Le SYN Flooding exploite ce m�canisme
d'�tablissement en trois phases. Les trois �tapes sont l'envoi d'un
SYN, la r�ception d'un SYN-ACK et l'envoi d'un ACK. Le principe est de
laisser sur la machine cible un nombre important de connexions TCP en
attentes. Pour cela, le pirate envoie un tr�s grand nombre de demandes
de connexion (flag SYN � 1), la machine cible renvoie les SYN-ACK
en r�ponse au SYN re�us. Le pirate ne r�pondra jamais avec un ACK, et
donc pour chaque SYN re�u la cible aura une connexion TCP en
attente. Etant donn� que ces connexions semi-ouvertes consomment des
ressources m�moires au bout d'un certain temps la machine est satur�e
et ne peut plus accepter de connexion. Ce type de d�ni de service
n'affecte que la machine cible.
</p><p>
Le pirate utilise un SYN Flooder comme synk4, en indiquant le port TCP
cible et l'utilisation d'adresses IP source al�atoires pour �viter
toute identification de la machine du pirate.
</P>
<H3>UDP Flooding</H3>
<P> Ce d�ni de service exploite le mode non connect� du protocole
UDP. Il cr�e un "UDP Packet Storm" (g�n�ration d'une grande quantit�
de paquets UDP) soit � destination d'une machine soit entre deux
machines. Une telle attaque entre deux machines entra�ne une
congestion du r�seau ainsi qu'une saturation des ressources des deux
h�tes victimes. La congestion est plus importante du fait que le
trafic UDP est prioritaire sur le trafic TCP. En effet, le protocole
TCP poss�de un m�canisme de contr�le de congestion, dans le cas o�
l'acquittement d'un paquet arrive apr�s un long d�lai, ce m�canisme
adapte la fr�quence d'�mission des paquets TCP, le d�bit diminue. Le
protocole UDP ne poss�de pas ce m�canisme, au bout d'un certain temps
le trafic UDP occupe donc toute la bande passant n'en laissant qu'une
infime partie au trafic TCP.
</p><p>
L'exemple le plus connu d'UDP Flooding est le <em>Chargen Denial of
Service Attack</em>. La mise en pratique de cette attaque est simple,
il suffit de faire communiquer le service <code>chargen</code> d'une
machine avec le service <code>echo</code> d'une autre. Le service
<code>chargen</code> g�n�re des caract�res tandis que
<code>echo</code> se contente de r��mettre les donn�es qu'il
re�oit. Il suffit alors au pirate d'envoyer des paquets UDP sur le
port 19 (<code>chargen</code>) � une des victimes en spoofant
l'adresse IP et le port source de l'autre. Dans ce cas le port source
est le port UDP 7 (<code>echo</code>). L'UDP Flooding entra�ne une
saturation de la bande passante entres les deux machines. Un r�seau
complet peut donc �tre victime d'un UDP Flooding.
</P>
<H3>Packet Fragment</H3>
<P>
Les d�nis de service de type Packet Fragment utilisent des faiblesses
dans l'impl�mentation de certaines pile TCP/IP au niveau de la
d�fragmentation IP (r�assemblage des fragments IP).
</p><p>
Une attaque connue utilisant ce principe est Teardrop. L'offset de
fragmentation du second fragment est inf�rieur � la taille du premier
ainsi que l'offset plus la taille du second. Cela revient � dire que
le deuxi�me fragment est contenu dans le premier (overlapping). Lors
de la d�fragmentation certains syst�mes ne g�rent pas cette exception et
cela entra�ne un d�ni de service. Il existe des variantes de cette
attaque : bonk, boink et newtear par exemple. Le d�ni de service
Ping of Death exploite une mauvaise gestion de la d�fragmentation au
niveau ICMP, en envoyant une quantit� de donn�es sup�rieure � la
taille maximum d'un paquet IP. Ces diff�rents d�nis de services
aboutissent � un crash de la machine cible.
</P>
<H3>Smurfing</H3>
<P> Cette attaque utilise le protocole ICMP. Quand un ping (message
ICMP ECHO) est envoy� � une adresse de broadcast (par exemple
10.255.255.255), celui-ci est d�multipli� et envoy� � chacune des
machines du r�seau. Le principe de l'attaque est de spoofer les
paquets ICMP ECHO REQUEST envoy�s en mettant comme adresse IP source
celle de la cible. Le pirate envoie un flux continu de ping vers
l'adresse de broadcast d'un r�seau et toutes les machines r�pondent
alors par un message ICMP ECHO REPLY en direction de la cible. Le flux
est alors multipli� par le nombre d'h�te composant le r�seau. Dans ce
cas tout le r�seau cible subira le d�ni de service, puisque l'�norme
quantit� de trafic g�n�r� par cette attaque entra�ne une congestion
du r�seau. </P>
<H3>D�ni de service distribu�</H3>
<P>
Les d�nis de services distribu�s saturent le r�seau victime. Le principe
est d'utiliser plusieurs sources (daemons) pour l'attaque et des
ma�tres (masters) qui les contr�lent. Les outils de DDoS
(<em>Distributed Denial of Service</em>) les plus connus sont Tribal
Flood Network (TFN), TFN2K, Trinoo et Stacheldraht. La figure 13 montre un
r�seau typique de DDoS : <br><br>
Pic.13: R�seau DDoS<br>
<img src="../../common/images/article282/ddos.jpg" alt="ddos"
width="491" height="222"></p>
</p><p>
Le pirate utilise des ma�tres pour contr�ler plus facilement les
sources. En effet, il a besoin de se connecter (en TCP) aux ma�tres
pour configurer et pr�parer l'attaque. Les ma�tres se contentent
d'envoyer des commandes aux sources en UDP. S'il n'y avait pas les
ma�tres, le pirate serait oblig� de se connecter � chaque source. La
source de l'attaque serait d�tect�e plus facilement et sa mise en
place beaucoup plus longue.
</p><p>
Chaque daemon et master discutent en �changeant des messages
sp�cifiques selon l'outil utilis�. Ces communications peuventt m�me
�tre crypt�es et/ou authentifi�es. Pour installer les daemons et les
masters, le pirate utilise des failles connues (buffer overflow sur
des services RPC, FTP ou autres). L'attaque en elle-m�me est un SYN
Flooding, UDP Flooding ou autre Smurf Attack. Le r�sultat d'un d�ni de
service est donc de rendre un r�seau inaccessible.
</P>
<h2>Conclusion</h2>
<p>
Aujourd'hui, la s�curit� contre les attaques � distance se renforce
de plus en plus contrairement � la s�curit� interne. Ce parent pauvre
de la protection contre les pirates laisse encore de belles perspectives
� des attaques en local comme le TCP Session Hijacking, l'ARP Spoofing
et le DNS Spoofing. Par ailleurs, la pr�diction de num�ro de s�quence
(coeur de l'IP Spoofing) et les variantes de Fragments Attacks apparaissent
uniquement � cause de bugs au niveau des OS des �quipements r�seaux. En ce
qui concerne les attaques applicatives, elles ont encore de beaux jours
devant elles gr�ce � la complexit� sans cesse croissante des applications
li�es au Web et aux d�lais de plus en plus courts impos�s aux d�veloppeurs
et aux administrateurs. Quant aux d�nis de service, ils seront toujours
aussi redoutables dans leur forme distribu�e tant que tout le monde ne sera
pas sensibilis� � la protection de leur machine personnelle.
</p>
<hr>
<h2>Liens</h2>
<ul>
<li>RFC 1858 - Security Considerations for IP Fragment Filtering :
<a href="http://sunsite.dk/RFC/rfc/rfc1858.html">
sunsite.dk/RFC/rfc/rfc1858.html</a></li>
<li>IP Spoofing Demystified - Phrack 48 :
<a href="http://www.phrack.org/">
www.phrack.org/</a></li>
<li>Simple Active Attack Against TCP - Laurent Joncheray :
<a href="http://www.insecure.org/stf/iphijack.txt">
www.insecure.org/stf/iphijack.txt</a></li>
<li>DNS ID Hacking - ADM Crew :
<a href="http://packetstorm.securify.com/groups/ADM/ADM-DNS-SPOOF/ADMID.txt">
packetstorm.securify.com/groups/ADM/ADM-DNS-SPOOF/ADMID.txt</a> </li>
<li>The DoS Project's "trinoo" - David Dittrich :
<a href="http://staff.washington.edu/dittrich/misc/trinoo.analysis">
staff.washington.edu/dittrich/misc/trinoo.analysis</a></li>
<li>The Strange Tale of the DENIAL OF SERVICE Attacks against GRC.COM :
<a href="http://grc.com">
grc.com</a></li>
<li>hping2 :
<a href="http://www.kyuzz.org/antirez/hping.html">
www.kyuzz.org/antirez/hping.html</a></li>
<li>nemesis :
<a href="http://www.packetfactory.net/Projects/nemesis/">
www.packetfactory.net/Projects/nemesis/</a></li>
<li>mendax :
<a href="http://packetstorm.securify.com/Exploit_Code_Archive/mendax_linux.tgz">
packetstorm.securify.com/Exploit_Code_Archive/mendax_linux.tgz</a></li>
<li>hunt :
<a href="http://lin.fsid.cvut.cz/~kra/index.html">
lin.fsid.cvut.cz/~kra/index.html</a></li>
<li>dsniff :
<a href="http://www.monkey.org/~dugsong/dsniff/">
www.monkey.org/~dugsong/dsniff/</a></li>
<li>fragrouter :
<a href="http://packetstorm.securify.com/UNIX/IDS/fragrouter-1.6.tar.gz">
packetstorm.securify.com/UNIX/IDS/fragrouter-1.6.tar.gz</a></li>
</ul>
</body>
</html>