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

[Paul Graham]

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:

On Sun, Nov 05, 2017 at 04:09:37PM +0100, Andreas Metzler wrote:

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

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



--
Paul Graham
Development Dept.
http://Omega-Software.com/

Omega Software

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

[Paul Graham]

Hi!


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

On Sun, Nov 05, 2017 at 04:09:37PM +0100, Andreas Metzler wrote:

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

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?

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.

--
Paul Graham
Development Dept.
http://Omega-Software.com/

Omega Software

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

[Paul Graham]

Hi!


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



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 do not see the attacker gain, the same information can be extracted by
trying out RCPT TO *@omega-software.com with FROM attac...@gmail.com.


Indeed :-)

We even had one of those, this morning:

2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attac...@example.com> rejected RCPT 
<te...@omega-software.com>: Unrouteable address
2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attac...@example.com> rejected RCPT 
<te...@omega-software.com>: Unrouteable address
2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attac...@example.com> rejected RCPT 
<te...@omega-software.com>: Unrouteable address

2017-11-05 09:24:14 H=(attacker) [10.20.30.40] F=<attac...@example.com> rejected RCPT 
<validaddr...@omega-software.com>: SPF check failed.


What am I missing?


This one can be solved too (mostly). Usually they fail some of the other 
checks. In this case SPF but it could be reverse DNS, DNSBL or other. Same 
problem: they can tell the difference because they get a different message.

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).

--
Paul Graham
Development Dept.
http://Omega-Software.com/

Omega Software
--- 30_exim4-config_check_rcpt_sender	2017-11-05 15:06:25.839001108 +0100
+++ exim4-4.86.2-patched/debian/debconf/conf.d/acl/30_exim4-config_check_rcpt	2017-11-05 15:07:54.158520031 +0100
@@ -189,12 +189,6 @@
 !verify = sender
   .endif
 
-  # We also require all accepted addresses to be verifiable. This check will
-  # do local part verification for local domains, but only check the domain
-  # for remote domains.
-  require
-verify = recipient
-
 
   # Verify recipients listed in local_rcpt_callout with a callout.
   # This is especially handy for forwarding MX hosts (secondary MX or
@@ -340,6 +334,16 @@
   .include CHECK_RCPT_LOCAL_ACL_FILE
   .endif
 
+  # Recipient check leaks information about which local accounts exist.
+  # This could be exploited in a brute-force scan to find valid addresses (usually
+  # for spam purposes). Performing this check last gives the other checks a chance
+  # to deny the request before they succeed at extracting this information.
+
+  # We also require all accepted addresses to be verifiable. This check will
+  # do local part verification for local domains, but only check the domain
+  # for remote domains.
+  require
+verify = recipient
 
   #
   # This check is commented out because it is recognized that not every

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

[Paul Graham]

Package: exim4-config
Version: 4.90~RC1-1
Severity: normal

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= 
rejected RCPT : Sender verify failed
2017-11-03 16:22:39 H=(ws2008) [10.20.30.40] F= 
rejected RCPT : Sender verify failed
2017-11-03 16:22:40 H=(ws2008) [10.20.30.40] F= 
rejected RCPT : Sender verify failed

2017-11-03 16:22:42 H=(ws2008) [10.20.30.40] 
F= rejected RCPT : 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 ***


-- Package-specific info:
Exim version 4.86_2 #2 built 03-Jun-2017 05:07:28
Copyright (c) University of Cambridge, 1995 - 2015
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2015
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC PRDR 
OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-37-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages exim4-config depends on:
ii  adduser3.113+nmu3ubuntu4
ii  debconf [debconf-2.0]  1.5.58ubuntu1

exim4-config recommends no packages.

exim4-config suggests no packages.

-- Configuration Files:
/etc/email-addresses changed [not included]
/etc/exim4/conf.d/acl/30_exim4-config_check_rcpt changed [not included]
/etc/exim4/conf.d/acl/40_exim4-config_check_data changed [not included]
/etc/exim4/conf.d/auth/30_exim4-config_examples changed [not included]
/etc/exim4/conf.d/main/03_exim4-config_tlsoptions changed [not included]
/etc/exim4/exim4.conf.template changed [not included]

-- debconf information excluded
--- 30_exim4-config_check_rcpt_orig	2017-11-05 15:13:31.253064618 +0100
+++ 30_exim4-config_check_rcpt_sender	2017-11-05 15:15:15.076702584 +0100
@@ -107,24 +107,6 @@
 domains = +local_domains : +relay_to_domains
 
 
-  # Deny unless the sender address can be verified.
-  #
-  # This is disabled by default so that DNSless systems don't break. If
-  # your system can do DNS lookups without delay or cost, you might want
-  # to enable this feature.
-  #
-  # This feature does not work in smarthost and satellite setups as
-  # with these setups all domains pass verification. See spec.txt section
-  # "Access control lists" subsection "Address verification" with the added
-  # information that a smarthost/satellite setup routes all non-local e-mail
-  # to the smarthost.
-  .ifdef CHECK_RCPT_VERIFY_SENDER
-  deny
-message = Sender verification failed
-!acl = acl_local_deny_exceptions
-!verify = sender
-  .endif
-
   # Verify senders listed in local_sender_callout with a callout.
   #
   # In smarthost and satellite setups, this causes the callout to be
@@ -183,6 +165,34 @@
 message = relay not permitted
 domains = +local_domains : +relay_to_domains
 
+  # If sender check is enabled, it should be after relay check. Otherwise, it
+  # would be possible to tell if a local address exists by attempting to send
+  # a mail with:
+  # - the targetted local address as sender
+  # - an arbitrary remote address as recipient
+  # Thus if the mail were rejected with "relay not permitted", this means it
+  # passed sender verification.
+  #
+  # This could be exploited in a brute-force scan to find valid addresses (usually
+  # for spam purposes).
+
+  #