À noter que si on a configuré OpenSmtpd pour stocker les mails au format Maildir, la faille est sans effet.
On reçoit des mails cherchant clairement à exploiter la faille avec toutes les commandes que l'attaquant essaie d'exécuter, avec en particulier des adresses IPs, le serveur SMTP d'origine etc.
L'équipe d'OpenSMTPD l'explique ici : https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_smtpd_exec.patch.sig
Si on utilise mbox alors on peut exécuter en tant que root, si on utilise lmtp (pour transférer à dovecot par exemple qui se chargera du stockage local), on peut exécuter en utilisateur normal.
Ce n'est pas indiqué, mais apparemment si on utilise maildir, rien n'est exécuté.
accept from any for domain <domains> virtual <aliases> userbase <userinfo> deliver to maildir
Return-Path: ;touch /tmp/plop;@DOMAIN.NAME
Delivered-To: root@DOMAIN.NAME
Received: from yth.o.gtha (localhost [127.0.0.1])
by SMTP.DOMAIN.NAME (OpenSMTPD) with SMTP id a224891f
for <root@DOMAIN.NAME>;
Tue, 11 Feb 2020 19:59:00 +0000 (UTC)
Date: Tue, 11 Feb 2020 19:59:00 +0000 (UTC)
Message-Id: <6bcbfe674b0672dd@DOMAIN.NAME>
Le fichier /tmp/plop n'est jamais créé.
Je n'exclue pas la possibilité qu'autre chose dans ma configuration puisse annuler les effets de la faille, je n'ai pas poussé plus loin.
En attendant c'est marrant je vois passer des tentatives d'exploitation de la faille, qui passent par TOR donc pas complètement noobs, mais avec de vraies Ip en dur et tout, des URLs avec des scripts à télécharger pour installer des backdoors en perl, ou l'utilisation de netcat pour ouvrir un flux inverse.
C'est bien, je garde tout, ça peut donner des idées pour des trucs à-la-con pour bloquer une intrusion.
Je tiens à préciser que le serveur en question n'a rien de critique, tout à fait personnel, mono-utilisateur, je ne joue qu'avec moi-même !
Posté par Yth (Mastodon) .
Évalué à 6.
Dernière modification le 12 février 2020 à 20:55.
CVE annoncé le 29 janvier apparemment, chez moi les attaques ont commencées le 30 janvier.
J'ai vu tout de suite (à chaque fois je reçois un mail c'est très visible), et rapidement constaté que l'attaque ne fonctionnait pas.
Il m'a fallut quelques jours pour découvrir pourquoi.
Et ça continue encore aujourd'hui, 52 mails reçus, avec des séries, genre un premier censé télécharger un script qui est exécuté par le second.
Pas mal de tentative d'utiliser curl ou wget, ou netcat, voire de les installer au préalable.
J'essaie de garder les infos, et je mettrai tout ça ici - en forme - pour expliquer ce qu'« ils » essaient de faire.
# Annonces sécu
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
https://www.debian.org/security/2020/dsa-4611 (et https://security-tracker.debian.org/tracker/CVE-2020-7247 )
https://usn.ubuntu.com/4268-1/
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-7247
https://bugs.gentoo.org/show_bug.cgi?id=CVE-2020-7247
https://www.suse.com/security/cve/CVE-2020-7247/
…
[^] # Re: Annonces sécu
Posté par Yth (Mastodon) . Évalué à 3.
À noter que si on a configuré OpenSmtpd pour stocker les mails au format Maildir, la faille est sans effet.
On reçoit des mails cherchant clairement à exploiter la faille avec toutes les commandes que l'attaquant essaie d'exécuter, avec en particulier des adresses IPs, le serveur SMTP d'origine etc.
L'équipe d'OpenSMTPD l'explique ici : https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_smtpd_exec.patch.sig
Si on utilise mbox alors on peut exécuter en tant que root, si on utilise lmtp (pour transférer à dovecot par exemple qui se chargera du stockage local), on peut exécuter en utilisateur normal.
Ce n'est pas indiqué, mais apparemment si on utilise maildir, rien n'est exécuté.
Et un test inspiré de ce qu'on trouve ici :
https://seclists.org/fulldisclosure/2020/Jan/49
Le fichier /tmp/plop n'est jamais créé.
Je n'exclue pas la possibilité qu'autre chose dans ma configuration puisse annuler les effets de la faille, je n'ai pas poussé plus loin.
En attendant c'est marrant je vois passer des tentatives d'exploitation de la faille, qui passent par TOR donc pas complètement noobs, mais avec de vraies Ip en dur et tout, des URLs avec des scripts à télécharger pour installer des backdoors en perl, ou l'utilisation de netcat pour ouvrir un flux inverse.
C'est bien, je garde tout, ça peut donner des idées pour des trucs à-la-con pour bloquer une intrusion.
Je tiens à préciser que le serveur en question n'a rien de critique, tout à fait personnel, mono-utilisateur, je ne joue qu'avec moi-même !
[^] # Re: Annonces sécu
Posté par David Marec (site web personnel) . Évalué à 2.
Tout à fait, seul le format
mboxpose problème.Eh bé, ça n'a pas trainé.
Je serais curieux de savoir si les attaques ont démarré dès l'annonce de la faille, ou à partir de la publication du CVE.
[^] # Re: Annonces sécu
Posté par Yth (Mastodon) . Évalué à 6. Dernière modification le 12 février 2020 à 20:55.
CVE annoncé le 29 janvier apparemment, chez moi les attaques ont commencées le 30 janvier.
J'ai vu tout de suite (à chaque fois je reçois un mail c'est très visible), et rapidement constaté que l'attaque ne fonctionnait pas.
Il m'a fallut quelques jours pour découvrir pourquoi.
Et ça continue encore aujourd'hui, 52 mails reçus, avec des séries, genre un premier censé télécharger un script qui est exécuté par le second.
Pas mal de tentative d'utiliser curl ou wget, ou netcat, voire de les installer au préalable.
J'essaie de garder les infos, et je mettrai tout ça ici - en forme - pour expliquer ce qu'« ils » essaient de faire.
Yth.
[^] # Re: Annonces sécu
Posté par David Marec (site web personnel) . Évalué à 2.
L'annonce «ouverte» la plus ancienne date du 28 au soir.
Des attaques lancées en à peine une journée donc.
Dingue.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.