Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, mars 26 2009

Les spammeurs savent utiliser AUTH LOGIN ... et ma configuration FAIL

"Tiens, on dirait que j'ai de moins en moins d'emails ces temps-ci ....". C'est par cette triste pensée que débuta ma recherche de la cause du problème. En effet, je possède un serveur dédié comme nombre de passionnés. Et bien sûr, mon serveur dédié héberge de multiples domaines. Mais surtout, un serveur SMTP pour dans les ténèbres les lier. C'est de ce dernier et de sa configuration dont je vais parler aujourd'hui.

Donc, je ne reçois presque plus de mails. Première hypothèse, plus personne ne m'aime. Non, ça ne tiens pas, j'ai pas été plus méchant ces temps-ci que les temps précédents. Deuxième hypothèse, ma mail queue commence à saturer. Je me connecte en SSH, et là, c'est le drame. Le mailq me donne une liste qui défile pendant près d'une minute. Je traduis pour les incultes : ça veut dire beaucoup beaucoup de messages en attente de livraison.

Mais pourquoi donc que c'est comme ça ? En regardant rapidement, je vois que 80% des messages sont à destination de personnes ayant (ou pas) un mail @yahoo.com.tw. Avec un peu de chance, je n'ai qu'un spammeur qui a repéré une faiblesse chez moi.

Je tente un premier truc : bloquer les adresses IP sources qui me mettent ces messages @yahoo.com.tw dans ma queue (huhu). Mais comme prévu, la liste est longue; je ne retiens pas cette solution. Par contre, en attendant de trouver mieux, je bloque les messages sortant à destination des IP des MX de yahoo.com.tw afin de les décharger de ce load. Sympa knorr.

Deuxième truc : analyser les commandes SMTP. Je capture le trafic SMTP sur mon serveur pendant quelques minutes pour avoir de quoi jouer. Après analyse, voici les data qui me semblent intéressantes :

> EHLO msg-g09pmirpcam
< 250-ns22829.ovh.net
< 250-AUTH LOGIN CRAM-MD5 PLAIN
< 250-AUTH=LOGIN CRAM-MD5 PLAIN
< 250-PIPELINING
< 250 8BITMIME
> AUTH LOGIN
< 334 VXNlcm5hbWU6
> YWRtaW4=
< 334 UGFzc3dvcmQ6
> YWRtaW4=
< 235 ok, go ahead (#2.0.0)
> RSET
> MAIL FROM:<fkp@ns22829.ovh.net>
> RCPT TO:<oprah2073@yahoo.com.tw>
...
> DATA
< 250 flushed
< 250 ok
...
< 354 go ahead
> From: =?BIG5?B?uFW+8KRI?= <fkp@ns22829.ovh.net>
> To: "oprah2073" <oprah2073@yahoo.com.tw>
> Subject: =?BIG5?B?obShtKG0obSkQK3TpKOlsqnxsfOnQaq6pHWnQLROpWm8V6VbpqykSqq6pOiqa6G0?==?BIG5?B?obShtKG0obShtA==?=
> Date: Tue, 19 Jan 2038 11:14:07 +0800
...
< 250 ok 1237657002 qp 1924

Mais que vois-je ? mon serveur accepte les messages à destination d'un domaine que je n'héberge pas ? En l'occurrence, les messages à destination de yahoo.com.tw. Mais pourquoi tant de haine ? En regardant le début de la transaction, je note l'utilisation de AUTH LOGIN. En regardant encore mieux, non seulement la négociation n'échoue pas, mais en plus elle réussit !

Avant de vous traduire le dialogue, oui, pour vous, pauvres mécréants, un petit mot sur AUTH LOGIN. Mon serveur SMTP est (était) configuré pour utiliser la méthode SMTP AUTH LOGIN. Cette méthode permet aux seuls utilisateurs ayant un compte sur mon serveur (je simplifie) de s'authentifier en SMTP, et de se voir attribuer le droit de pouvoir utiliser mon serveur SMTP pour relayer tous leurs messages. Ai confiance en tes users :) L'intérêt est pour eux de ne pas avoir besoin d'utiliser le webmail de mon serveur pour expédier des messages provenant de leur nom de domaine. Mais leur client de messagerie se doit de supporter AUTH LOGIN. Revenons à notre traduction :

> AUTH LOGIN
# Can I haz authenticashun to spam teh interwebs ?
< 334 VXNlcm5hbWU6
# base64_decode => 'Username:'
> YWRtaW4=
# base64_decode => 'admin'
< 334 UGFzc3dvcmQ6
# base64_decode => 'Password:'
> YWRtaW4=
# base84_decode => 'admin'
< 235 ok, go ahead (#2.0.0)
# authentication: WIN

Caugh, caugh. Vous lisez bien, admin/admin et le spammeur est authentifié sur mon serveur. Je me bas presque tous les jours pour que les gens changent les mots de passe par défaut. C'est pas dur merde ! Bon, que celui qui n'a jamais fauté jette la première pêche.

A ma décharge, la faille de configuration de mon serveur était plus sévère. N'importe quel couple login/mot de passe était accepté, et permettait de s'authentifier.

Je recompile donc qmail en désactivant le support AUTH LOGIN, n'ayant pas d'utilisateur s'en servant. Si ils me le demandent, je regarderai de plus près comment configurer ça de manière secure. Je redémarre qmail. Je regarde ma mailq. Je capture du trafic. J'analyse le trafic ... nan, c'est bon :) c'est corrigé. Mais la chose amusante, c'est que le spammeur en question n'utilise plus la méthode AUTH LOGIN. Voyons le nouveau trafic :

< 220 ns22829.ovh.net ESMTP
> EHLO msg-g09pmirpcam
< 250-ns22829.ovh.net
< 250-PIPELINING
< 250 8BITMIME
< RSET
< 250 flushed
> MAIL FROM:<ins@ns22829.ovh.net>
> RCPT TO:<roety503@yahoo.com.tw>
...
< 250 ok
< 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
...

Voilà qui va beaucoup mieux. Mais vous avez remarqué ? le spammeur n'utilise plus la méthode AUTH LOGIN. Ce qui veut dire que son robot analyse la sortie de la commande EHLO, et si le serveur SMTP supporte AUTH LOGIN, il tente une authentification. Au moins avec admin/admin. Je ne vais pas analyser plus que ça, mais il est possible que le robot brute-force un minimum avec différents couples login/mot de passe. Intéressant spammeur, on se reverra peut-être. A+