Re: [Exim] request for help: CAN-1999-0531 expn exploitation

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Exim Users Mailing List
Dátum:  
Címzett: freelsjd
CC: exim-users
Tárgy: Re: [Exim] request for help: CAN-1999-0531 expn exploitation
[ On Monday, November 19, 2001 at 13:37:21 (-0500), James D. Freels wrote: ]
> Subject: [Exim] request for help: CAN-1999-0531 expn exploitation
>
> but I am still getting the same response from the "Xforce ISS" scanners.
> Since I am not using sendmail, then there appears to be a problem. I
> would appreciate any solution offered.


There is probably no problem to worry about. The Xforce ISS scanner is,
like most such products, a fear-mongering over-zealous worry-wart that
makes tremendous assumptions about how sendmail in particular works.
You should simply ignore it if you do not understand the issue in depth.

You cannot use the information provided by a generic security scanner
unless you have a very well designed security policy and you know how to
implement technical controls to enforce it. Now I am not trying to say
you don't to have a properly written security policy, or that you don't
know how to implement it with technical controls. I am saying however
that blindly following the advice of any security scanner is _never_ a
good idea, and that appears to be what you're trying to do, for whatever
reason. Blindly following such advice can usually only lead to having a
false sense of security, and that can be worse than no security at all.
You can only use a security scanner effectively if you use it to monitor
the accuracy and completeness of your security policy implementation,
not the other way around.

Note that even if you do allow the SMTP VRFY and EXPN commands there's
probably no additional risk (though EXPN might open you up to getting
more of your users on spammer lists, which may or may not be something
covered by your security policy).

To understand these security risks properly you have to understand
what's really being revealed, and how this information might be
available through other obvious sources to an attacker, and how the
attacker might be able to use this information against your specific
systems in particular.

I.e. you need to know what's going on explicitly with how SMTP is used
on your systems, and how information in e-mail addresses can be a threat
to your system(s). Then once you have all that knowledge you can
conduct a real and proper risk assessment that is not biased by the
overly generic advice from a program which is at least partially
designed explicitly to provide additional revenue streams to its vendor
(though even Nessus is similarly useless in this regard).

SMTP VRFY reveals nothing beyond what "RCPT TO:" will reveal, or indeed
what passive listening to your external SMTP traffic will reveal, or
even what scanning of various public Internet archives (google, google
groups, etc.) is likely to reveal.

SMTP EXPN may not reveal anything more either -- it all depends on
exactly how you use your external mailer and whether or not it hosts any
mailing lists. If you host mailing lists then SMTP EXPN may allow
anyone to harvest those lists. At best this will make it easy for a
spammer to collect more addresses, and at worst it might reveal all
account-names on your system(s) (eg. if you've got an "office" alias or
such that lists every user).

If you really want to use "security by obscurity" to "raise the bar" by
hiding account names then you _MUST_ ensure that your external mailer
_NEVER_ delivers to local accounts and that local system account names
CANNOT be derived by any algorithm from the mailbox names you expose to
the public Internet (or any other internet which you consider a threat
of some sort), _AND_ that there's no other way for external attackers to
readily learn account names. I.e. this kind of security by obscurity
must be only a tiny part of a very much larger policy implementation.

Generally speaking it's unlikely that the total costs of turning off
VRFY will outweigh the risks, but turning off EXPN is less costly
overall and far more of a risk IFF you host any mailing lists on the
server in question. This is because on monolithic mailers such as Exim
(and smail and sendmail) VRFY and EXPN are very valuable debugging
tools, not just for you but also for remote postmasters you do not know
and thus the "cost" of turning them off is much higher in total than
just the administrative overhead of changing the mailer's configuration.

I.e. you should turn off EXPN, leave VRFY enabled, and completely ignore
ISS on this matter. :-)

That does appear to be how at least three of the ornl.gov mailers your
message passed through on its way to the exim-users list are configured....

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>     <woods@???>
Planix, Inc. <woods@???>;   Secrets of the Weird <woods@???>