#880905 exim4-config: Sender verification could be exploited for brute-force scan

Package:
exim4-config
Source:
exim4
Submitter:
Paul Graham
Date:
2017-11-06 21:51:06 UTC
Severity:
normal
#880905#5
Date:
2017-11-05 14:29:07 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

This recently came up in Exim logs:

2017-11-03 16:22:39 H=(ws2008) [10.20.30.40] F=<test1@omega-software.com> rejected RCPT <attacker@gmail.com>: Sender verify failed
2017-11-03 16:22:39 H=(ws2008) [10.20.30.40] F=<test2@omega-software.com> rejected RCPT <attacker@gmail.com>: Sender verify failed
2017-11-03 16:22:40 H=(ws2008) [10.20.30.40] F=<test3@omega-software.com> rejected RCPT <attacker@gmail.com>: Sender verify failed
....
2017-11-03 16:22:42 H=(ws2008) [10.20.30.40] F=<validaddress@omega-software.com> rejected RCPT <attacker@gmail.com>: relay not permitted

It reveals that an attacker took advantage that sender verification happens before relay checks to perform a brute force scan that revealed valid addresses in our domain.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

We moved sender verification so that it happens after relay check.

   * What was the outcome of this action?

After this change, it's no longer possible for an attacker to use this technique to extract information. All their attempts would result in "relay not permitted" regardless of sender address.

I'm attaching a patch. Note our server runs 4.86 on Ubuntu but the patch is for exim 4.90~RC1-1.

*** End of the template - remove these template lines ***
#880905#10
Date:
2017-11-05 15:09:37 UTC
From:
To:
[...]
[...]

I do not see the attacker gain, the same information can be extracted by
trying out RCPT TO *@omega-software.com with FROM attacker@gmail.com.

What am I missing?

cu Andreas
#880905#15
Date:
2017-11-05 16:03:03 UTC
From:
To:
Hi!


At 05/11/17 16:09, Andreas Metzler wrote:

Indeed :-)

We even had one of those, this morning:

2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attacker@example.com> rejected RCPT <test1@omega-software.com>: Unrouteable address
2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attacker@example.com> rejected RCPT <test2@omega-software.com>: Unrouteable address
2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attacker@example.com> rejected RCPT <test3@omega-software.com>: Unrouteable address
....
2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attacker@example.com> rejected RCPT <validaddress@omega-software.com>: SPF check failed.

So we mitigated this case by moving the recipient check too. Not just after relay, but after all the other checks that could potentially reject the attempt.

Here's the patch for that. If you want I can send a separate report (that was my initial intent).
#880905#20
Date:
2017-11-05 17:59:52 UTC
From:
To:
Additionally, we are desperately trying to stay close to the upstream
configuration. If this is really an issue, then all non-Debian exim
installations are vulnerable as well.

What I am trying to say is, this issue should be reported and
discussed with upstream _before_ we make this change. Paul, can you do
that to make your point there?

Greetings
Marc
#880905#25
Date:
2017-11-05 20:11:57 UTC
From:
To:
Hi!


At 05/11/17 18:59, Marc Haber wrote:
Yes of course. As moving sender verification is only useful if recipient verification is moved, I'll make my point for recipient verification first then.

If they're receptive I'll bring up sender verification after that.
#880905#30
Date:
2017-11-06 21:47:28 UTC
From:
To:
Hi

Same as I told Exim devs: we finally opted for enabling Exim support in fail2ban. This gives better result for all brute-force attempts as they're soon cut off and don't waste bandwidth.

Thanks for your feedback :)


At 05/11/17 18:59, Marc Haber wrote: