Mailing List Archive

Cyborg via Exim-users <exim-users@exim.org> (Mi 09 Jun 2021 21:13:43 CEST):
> Don#t get me wrong, exim is at the top of this "best of the worse" list,
> because it stops after 3 retriesm but other server like proftpd have already
> reacted to this by implementing countermeasures. This can also be seen in
> the mentioned figure.

The "3" is configurable:

|smtp_max_synprot_errors|Use: main|Type: integer|Default: 3|

So, if you worry about the abuse of your bandwidth and your Exim server,
then set this to zero. Should be enough to not be a part of this attack
vector, shouldn't it?

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -

Am 09.06.21 um 22:03 schrieb Heiko Schlittermann via Exim-users:
> Cyborg via Exim-users <exim-users@exim.org> (Mi 09 Jun 2021 21:13:43 CEST):
>> Don#t get me wrong, exim is at the top of this "best of the worse" list,
>> because it stops after 3 retriesm but other server like proftpd have already
>> reacted to this by implementing countermeasures. This can also be seen in
>> the mentioned figure.
> The "3" is configurable:
>
> |smtp_max_synprot_errors|Use: main|Type: integer|Default: 3|
>
> So, if you worry about the abuse of your bandwidth and your Exim server,
> then set this to zero. Should be enough to not be a part of this attack
> vector, shouldn't it?
>

In the article, a reflextion attack is mentioned, so i may be important
what's coming back from the server. It may not be enough to just react
only once, but we will see, when more information is revealed.

I'm trying to get more infos about that attack vector from the german
universities which found it, and will make some tests if possible, so we
see what we actually have to defend against.

best regards,
Marius

--
## 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/

On 09/06/2021 22:10, Cyborg via Exim-users wrote:
> I'm trying to get more infos about that attack vector from the german universities which found it, and will make some tests if possible, so we see what we actually have to defend against.

"The attacks, however, hinge on the prerequisite that the perpetrator can intercept
and divert the victim's traffic at the TCP/IP layer."

It's beyond most script-kiddies, at least.

Email has no current standard for using ALPN; do we need one?
That is suggested as mitigation for this attack.
Exim does support SNI, which is also suggested (but only
used if explicitly configured, at present, unless DANE).

We might think about tightening up on the SNI defaults.

I guess using DANE counts as another defense against this attack.
--
Cheers,
Jeremy

--
## 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/

Am 10.06.21 um 11:18 schrieb Jeremy Harris via Exim-users:

> It's beyond most script-kiddies, at least.
>
> Email has no current standard for using ALPN; do we need one?
> That is suggested as mitigation for this attack.
> Exim does support SNI, which is also suggested (but only
> used if explicitly configured, at present, unless DANE).
>
> We might think about tightening up on the SNI defaults.
>
> I guess using DANE counts as another defense against this attack.

After reading the paper a bit closer, rejecting the entire connection
when a HTTP headerline is detected,
seems to be only valid option here, as long as ALPN isn't implemented
widely.

Heikos suggestion to set smtp_max_synprot_errors = 0 is the workaround
to go atm.

I suggest to change the default in the next exim release too.

Let's check if it's responable to change the default:

Next to noone is sending emails via manually entering text in telnet
connection.
Normal users will use clients, clientes know stmp protocol, so there
will be no harm in changing it.

Developers who need to test things, i.e. client devs or server admins,
will most likely use pre-typed scripts, because they usually need to
reexecute the tests over and over again. No harm here too.

I can't see one, that would be harmed by this change or did I overlook
something important?

@Heiko: always a pleasure, check the programm for next tuesday, you
might wanne join up.

best regards,
Marius


--
## 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/

On 10/06/2021 13:52, Cyborg via Exim-users wrote:
> After reading the paper a bit closer, rejecting the entire connection when a HTTP headerline is detected,
> seems to be only valid option here, as long as ALPN isn't implemented widely.

Do we need ACL-level visibilty of a synprot-rejected line?

> Heikos suggestion to set smtp_max_synprot_errors = 0 is the workaround to go atm.

But, ALPN implemented by what protocols?

If the common attack method uses HTTPS to attack an SMTP server, and the clients
for the former do ALPN, we could usefully update Exim to refuse TLS connections
offering any ALPN
(or, perhaps, any but "ESMTP" - though that really ought to be registered at
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
)

Doing that doesn't need any action or development on the part of other MTAs.
I'll admit it only helps for dumb attackers who use a ready-made webclient.

The next level would be something like
- server option hosts_require_alpn
- client options hosts_offer_alpn, hosts_require_alpn
And logging.
--
Cheers,
Jeremy

--
## 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/

Am 11.06.21 um 00:37 schrieb Jeremy Harris via Exim-users:
> On 10/06/2021 13:52, Cyborg via Exim-users wrote:
>> After reading the paper a bit closer, rejecting the entire connection
>> when a HTTP headerline is detected,
>> seems to be only valid option here, as long as ALPN isn't implemented
>> widely.
>
> Do we need ACL-level visibilty of a synprot-rejected line?
>

don't think so, as the first line of communication will be rejected,
there is no smtp happening.

>> Heikos suggestion to set smtp_max_synprot_errors = 0 is the
>> workaround to go atm.
>
> But, ALPN implemented by what protocols?
>
All, but esmtp. Thats the whole point of ALPN. "You reject whats not
intendet for you."


> The next level would be something like
> - server option hosts_require_alpn
> - client options hosts_offer_alpn, hosts_require_alpn
> And logging.

as a consequence, yes. ATM only a few others have adopted ALPN, so you
can plan and implement those features without any hurry.

I can imagine, that gnutls, libre and openssl  also need time to offer
api functions to support or enable this. So it will take time anyway,
before it can be implemented fully. For the moment, a reject reaction on
any HTTP/ header or a default of 0 protocol errors would be sufficient.

Best regards,
marius

--
## 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/

On 11/06/2021 07:58, Cyborg via Exim-users wrote:
> gnutls, libre and openssl  also need time to offer api functions

GnuTLS and OpenSSL support ALPN already, in current versions.
--
Cheers,
Jeremy

--
## 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/

Am 09.06.21 um 22:03 schrieb Heiko Schlittermann via Exim-users:
>
> |smtp_max_synprot_errors|Use: main|Type: integer|Default: 3|
>

A small follow-up on my change of this config on a -> very low traffic
<- mail-server in less than 18h after activation:

2021-06-10 17:09:54 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "HEAD / HTTP/1.0", NULL)
2021-06-10 17:09:55 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 17:09:56 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "GET /c/version.js
HTTP/1.1", NULL)
2021-06-10 17:09:58 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "GET
/streaming/clients_live.php HTTP/1.1", NULL)
2021-06-10 17:09:59 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "GET
/stalker_portal/c/version.js HTTP/1.1", NULL)
2021-06-10 17:10:01 SMTP call from [134.122.7.20] dropped: too many
syntax or protocol errors (last command was "GET /stream/live.php
HTTP/1.1", NULL)
2021-06-10 17:17:30 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "HEAD / HTTP/1.0", NULL)
2021-06-10 17:17:31 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 17:17:32 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 17:17:34 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /c/version.js
HTTP/1.1", NULL)
2021-06-10 17:17:35 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET
/streaming/clients_live.php HTTP/1.1", NULL)
2021-06-10 17:17:37 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET
/stalker_portal/c/version.js HTTP/1.1", NULL)
2021-06-10 17:17:39 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /client_area/
HTTP/1.1", NULL)
2021-06-10 17:17:40 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /stalker_portal/c/
HTTP/1.1", NULL)
2021-06-10 17:17:42 SMTP call from [138.197.154.233] dropped: too many
syntax or protocol errors (last command was "GET /stream/live.php
HTTP/1.1", NULL)
2021-06-10 19:08:50 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "HEAD / HTTP/1.0", NULL)
2021-06-10 19:08:51 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 19:08:51 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 19:08:51 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /c/version.js
HTTP/1.1", NULL)
2021-06-10 19:08:52 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET
/streaming/clients_live.php HTTP/1.1", NULL)
2021-06-10 19:08:52 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET
/stalker_portal/c/version.js HTTP/1.1", NULL)
2021-06-10 19:08:53 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /client_area/
HTTP/1.1", NULL)
2021-06-10 19:08:53 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /stalker_portal/c/
HTTP/1.1", NULL)
2021-06-10 19:08:53 SMTP call from [46.101.86.104] dropped: too many
syntax or protocol errors (last command was "GET /stream/live.php
HTTP/1.1", NULL)
2021-06-10 19:54:12 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "HEAD / HTTP/1.0", NULL)
2021-06-10 19:54:13 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 19:54:14 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "GET /c/version.js
HTTP/1.1", NULL)
2021-06-10 19:54:15 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "GET
/streaming/clients_live.php HTTP/1.1", NULL)
2021-06-10 19:54:17 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "GET
/stalker_portal/c/version.js HTTP/1.1", NULL)
2021-06-10 19:54:18 SMTP call from [134.122.5.182] dropped: too many
syntax or protocol errors (last command was "GET /stream/live.php
HTTP/1.1", NULL)
2021-06-10 20:21:18 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "HEAD / HTTP/1.0", NULL)
2021-06-10 20:21:19 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "GET /system_api.php
HTTP/1.1", NULL)
2021-06-10 20:21:20 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "GET /c/version.js
HTTP/1.1", NULL)
2021-06-10 20:21:21 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "GET
/streaming/clients_live.php HTTP/1.1", NULL)
2021-06-10 20:21:23 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "GET
/stalker_portal/c/version.js HTTP/1.1", NULL)
2021-06-10 20:21:24 SMTP call from [64.225.63.33] dropped: too many
syntax or protocol errors (last command was "GET /stream/live.php
HTTP/1.1", NULL)
2021-06-11 02:27:28 SMTP call from [192.241.214.95] dropped: too many
syntax or protocol errors (last command was "GET / HTTP/1.1", NULL)
2021-06-11 02:27:30 SMTP call from [192.241.214.95] dropped: too many
syntax or protocol errors (last command was "GET / HTTP/1.1", NULL)
2021-06-11 02:27:30 SMTP call from [192.241.214.95] dropped: too many
syntax or protocol errors (last command was "GET / HTTP/1.1", NULL)
2021-06-11 02:27:30 SMTP call from [192.241.214.95] dropped: too many
syntax or protocol errors (last command was "GET / HTTP/1.1", NULL)
2021-06-11 04:46:17 SMTP call from 92.118.160.1.netsystemsresearch.com
[92.118.160.1] dropped: too many syntax or protocol errors (last command
was "GET / HTTP/1.1", NULL)
2021-06-11 08:34:31 SMTP call from scanner-21.ch1.censys-scanner.com
[162.142.125.128] dropped: too many syntax or protocol errors (last
command was "GET / HTTP/1.1", NULL)
2021-06-11 08:34:36 SMTP call from scanner-21.ch1.censys-scanner.com
[162.142.125.128] dropped: too many syntax or protocol errors (last
command was "GET / HTTP/1.1", NULL)
2021-06-11 08:34:49 SMTP call from scanner-21.ch1.censys-scanner.com
[162.142.125.128] dropped: too many syntax or protocol errors (last
command was "GET / HTTP/1.1", NULL)
2021-06-11 08:34:50 SMTP call from scanner-21.ch1.censys-scanner.com
[162.142.125.128] dropped: too many syntax or protocol errors (last
command was "GET / HTTP/1.1", NULL)
2021-06-11 08:47:19 SMTP call from [45.113.70.146] dropped: too many
syntax or protocol errors (last command was "GET / HTTP/1.1", NULL)

Those are not Alpaca request, it just the normal everydays madness :D

I really don't wanne check on my normal or big servers

... and here is the EXIM EXPLOIT :
https://github.com/RUB-NDS/alpaca-code/blob/master/exploits/smtp/02-exim.md

(Exim does not suffer from this exploit, the browser which parses the
response is )


best regards,
Marius

--
## 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/

> ... and here is the EXIM EXPLOIT :
> https://github.com/RUB-NDS/alpaca-code/blob/master/exploits/smtp/02-exim.md

That's interesting because I expected a
503 no greeting received yet
if a throw a "mail from:..." to Exim before EHLO/HELO. But in the case the
address given is invalid it is indeed
501 <script>alert(1);</script>: malformed address: alert(1);</script> may
not follow <script>
without prior greeting.

According to debug +all output there is no way to prevent that by ACL
because none is called in this case....
mail from: <script>alert(1);</script>
12:33:23 1608459 SMTP<< mail from: <script>alert(1);</script>
12:33:23 1608459 LOG: smtp_syntax_error MAIN
12:33:23 1608459 SMTP syntax error in "mail from:
<script>alert(1);</script>" H=... malformed address: alert(1);</script> may
not follow <script>
12:33:23 1608459 SMTP>> 501 <script>alert(1);</script>: malformed address:
alert(1);</script> may not follow <script>

Maybe it's best to not reflect anything already known to be "malformed" to
the client? Or add an syntax_error ACL? Or call the command ACL even if a
syntax error is detected?

Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha@gmx.net> | https://www.blafasel.at/
Vienna University Computer Center | Austria

--
## 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/