Ce message expose une idée qui date de longtemps que je n'ai jamais eu le temps de travailler. Nous savons tous que la majorité des protocoles internet reposent sur un mécanisme client / serveur. Par exemple un client web (Firefox) demande une page web (index.html) à un serveur web (apache).
Il arrive que des serveurs doivent se comporter comme des clients. L'exemple le plus connu est celui du serveur de mail, qui accepte des mails en tant que serveur et les envoie au destinataire en tant que client. [On peut retrouver cette notion en HTTP, mais cela concerne plus les langages comme php qui se retrouvent client web.]. Nous savons que les serveurs sont attaqués et étudiés continuellement, mais qu'en est il de leur robustesse lorsqu'ils sont clients?
Le choix du serveur de mail apparaît comme intéressant. Il est présent à peu près partout et il est vraisemblablement possible de faire envoyer un mail depuis un serveur légitime sur un serveur pirate. Il faut trouver une adresse qui bounce, un mail de refus ou un mail légitime demandant une réponse vers un enregistrement MX que l'on maîtrise, et le serveur SMTP victime s'y connectera.
J'ai effectué une étude rapide sur sendmail. Lorsque je l'utilise en serveur, il est très strict sur la réception des commandes SMTP. Un écart à la RFC et la connexion coupe. Par contre, si je me fais passer pour un serveur et que je demande à sendmail de lui envoyer un mail, alors il devient beaucoup plus laxiste:
Sendmail -- Pirate
EHLO sendmail -->
<-- 502 Command not implemented
HELO sendmail -->
<-- 250 Ok
MAIL FROM: -->
<-- 250 Ok
RCPT TO: -->
<-- Test
<-- (1024 x le caractère A )
<-- d’autres caractères
<-- 250 Ok
DATA -->
<-- 354 Start mail
( mail )
. -->
<-- 250 Ok
QUIT -->
<-- 250 Ok
Ce test est moyennement concluant, je n'ai pas pu faire crasher sendmail, menant peut-être à une exploitation, mais j'ai montré qu'il est possible de sortir du chemin classique des RFC sans que sendmail ne le détecte. J'ai même pu envoyer une image iso sans problème, cela peut donc tout à fait être utilisé comme un canal de communication caché.
J'ai trouvé extrêmement peu de littérature à ce sujet. Il existe une vieille faille sur Exchange (datant de 2002) basée sur ce principe. Il reste à celui que ça intéresse de tester sur l'intégralité des serveurs SMTP disponibles ce genre d'attaques. Le nombre de commandes disponibles EHLO rend le test exhaustif des réponses encore un peu plus long.
Il arrive que des serveurs doivent se comporter comme des clients. L'exemple le plus connu est celui du serveur de mail, qui accepte des mails en tant que serveur et les envoie au destinataire en tant que client. [On peut retrouver cette notion en HTTP, mais cela concerne plus les langages comme php qui se retrouvent client web.]. Nous savons que les serveurs sont attaqués et étudiés continuellement, mais qu'en est il de leur robustesse lorsqu'ils sont clients?
Le choix du serveur de mail apparaît comme intéressant. Il est présent à peu près partout et il est vraisemblablement possible de faire envoyer un mail depuis un serveur légitime sur un serveur pirate. Il faut trouver une adresse qui bounce, un mail de refus ou un mail légitime demandant une réponse vers un enregistrement MX que l'on maîtrise, et le serveur SMTP victime s'y connectera.
J'ai effectué une étude rapide sur sendmail. Lorsque je l'utilise en serveur, il est très strict sur la réception des commandes SMTP. Un écart à la RFC et la connexion coupe. Par contre, si je me fais passer pour un serveur et que je demande à sendmail de lui envoyer un mail, alors il devient beaucoup plus laxiste:
Sendmail -- Pirate
EHLO sendmail -->
<-- 502 Command not implemented
HELO sendmail -->
<-- 250 Ok
MAIL FROM:
<-- 250 Ok
RCPT TO:
<-- Test
<-- (1024 x le caractère A )
<-- d’autres caractères
<-- 250 Ok
DATA -->
<-- 354 Start mail
( mail )
. -->
<-- 250 Ok
QUIT -->
<-- 250 Ok
Ce test est moyennement concluant, je n'ai pas pu faire crasher sendmail, menant peut-être à une exploitation, mais j'ai montré qu'il est possible de sortir du chemin classique des RFC sans que sendmail ne le détecte. J'ai même pu envoyer une image iso sans problème, cela peut donc tout à fait être utilisé comme un canal de communication caché.
J'ai trouvé extrêmement peu de littérature à ce sujet. Il existe une vieille faille sur Exchange (datant de 2002) basée sur ce principe. Il reste à celui que ça intéresse de tester sur l'intégralité des serveurs SMTP disponibles ce genre d'attaques. Le nombre de commandes disponibles EHLO rend le test exhaustif des réponses encore un peu plus long.
Aucun commentaire:
Enregistrer un commentaire