Autor: Todd Lyons Data: Para: Juergen Edner CC: exim-users Asunto: Re: [exim] Exim v4.72 - authenticating to server without having a
valid account
On Tue, Sep 7, 2010 at 10:34 AM, Juergen Edner
<juergen.edner@???> wrote: > Hello,
> I need your help to shed some light on a strange Spam abuse of an
> Exim server. I'm running a personal Exim server for years now
> without any problems. Today I've checked the last couple of mainlog
> files on the server and saw that something strange had happened at
> night.
> A user (name 'inna' or 'academia') was able to successfully authenticate
> to the server and sent mail over it although this user hasn't been
> set-up at all as a mail user. The same has happened on servers of some
> my friends.
> We checked the server configuration several times but weren't able to
> find any error which would allow to send email over it. In all cases the
> same login names have been used to authenticate email sending.
>
> I hope someone is a able to explain to me how it is possible to send
> email without even setting-up an account. Would it be possible that
> the spammer has caused a kind of buffer-overflow by sending to many
> nonmail commands to the server to abuse the system? Any help is highly
> appreciated.
>
> Some words about the Exim configuration:
> - The only inbound tcp-port which has been opened for incoming
> traffic from the Internet is 25/tcp (SMTP).
>
> - The users which are allowed to send email have been configured by
> adding them to a separate config file to make sure that different
> mail passwords are used.
>
> - Only authenticated users are allowed to send email over the Exim
> server. This is checked and logged by the following acls:
>
> acl_check_rcpt:
> ...
> require verify = sender
>
> accept sender_domains = +my_sender_domains
> endpass
> message = Only authenticated connections are allowed
> authenticated = *
> ...
>
> acl_check_data:
> ...
> warn set acl_m1 = 0
>
> # exiscan - check authentication
> warn authenticated = *
> set acl_m1 = 1
>
> warn logwrite = authenticated ($acl_m1) / authenticated_id
> ($authenticated_id)
> ...
>
> - The proper authentication is done by the following authenticator
> which checks the mail accounts against the credentials saved in
> a file in the format '<username> <password>'.
>
> fixed_cram:
> driver = cram_md5
> public_name = CRAM-MD5
> server_secret = "\
> ${if !eq{$1}{} \
> {${lookup{$1}lsearch{/etc/mail-users.pwd}{$value}}}fail}"
> server_set_id = $1
>
> - This is the part of the mainlog file which shows how it has been
> managed to abuse the mail server (I've stripped of the date and
> time stamp and added some comments in square brackets):
>
> ...
> fixed_cram authenticator failed for ns1.visto-web.com.br
> (rjntjhylw.com) [200.198.71.194]: 535 Incorrect authentication data
> [-> message repeated 5 times]
Is it always from this same IP?
If yes, then do:
tcpdump -n -p -s0 host 200.198.71.194 -w debug_auth.dump
...and let it run over night. If it happened in the logs for you that
night, then ctrl-c the tcpdump and run:
tcpdump -n -p -s0 -X -r debug_auth.dump | less
and look to see what he was sending that finally made it allowed.
That may not be very useful to see the content, but you should at
least see the negotiation portion and eliminate some possiblities.
--
Regards... Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm. -- Marcus Aurealius